* Re: [PATCH -next] iwlwifi: dbg: work around clang bug by marking debug strings static
From: Luca Coelho @ 2019-07-16 21:14 UTC (permalink / raw)
To: Nick Desaulniers, Joe Perches, Kalle Valo
Cc: Arnd Bergmann, Nathan Chancellor, Johannes Berg,
Emmanuel Grumbach, Intel Linux Wireless, David S. Miller,
Shahar S Matityahu, Sara Sharon, linux-wireless, netdev, LKML,
clang-built-linux
In-Reply-To: <CAKwvOdkD_r2YBqRDy-uTGMG1YeRF8KokxjikR0XLkXLsdJca0g@mail.gmail.com>
On Tue, 2019-07-16 at 10:28 -0700, Nick Desaulniers wrote:
> On Thu, Jul 11, 2019 at 7:15 PM Joe Perches <joe@perches.com> wrote:
> > On Thu, 2019-07-11 at 17:17 -0700, Nick Desaulniers wrote:
> > > Commit r353569 in prerelease Clang-9 is producing a linkage failure:
> > >
> > > ld: drivers/net/wireless/intel/iwlwifi/fw/dbg.o:
> > > in function `_iwl_fw_dbg_apply_point':
> > > dbg.c:(.text+0x827a): undefined reference to `__compiletime_assert_2387'
> > >
> > > when the following configs are enabled:
> > > - CONFIG_IWLWIFI
> > > - CONFIG_IWLMVM
> > > - CONFIG_KASAN
> > >
> > > Work around the issue for now by marking the debug strings as `static`,
> > > which they probably should be any ways.
> > >
> > > Link: https://bugs.llvm.org/show_bug.cgi?id=42580
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/580
> > > Reported-by: Arnd Bergmann <arnd@arndb.de>
> > > Reported-by: Nathan Chancellor <natechancellor@gmail.com>
> > > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> > > ---
> > > drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
> > > index e411ac98290d..f8c90ea4e9b4 100644
> > > --- a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
> > > +++ b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
> > > @@ -2438,7 +2438,7 @@ static void iwl_fw_dbg_info_apply(struct iwl_fw_runtime *fwrt,
> > > {
> > > u32 img_name_len = le32_to_cpu(dbg_info->img_name_len);
> > > u32 dbg_cfg_name_len = le32_to_cpu(dbg_info->dbg_cfg_name_len);
> > > - const char err_str[] =
> > > + static const char err_str[] =
> > > "WRT: ext=%d. Invalid %s name length %d, expected %d\n";
> >
> > Better still would be to use the format string directly
> > in both locations instead of trying to deduplicate it
> > via storing it into a separate pointer.
> >
> > Let the compiler/linker consolidate the format.
> > It's smaller object code, allows format/argument verification,
> > and is simpler for humans to understand.
>
> Whichever Kalle prefers, I just want my CI green again.
We already changed this in a later internal patch, which will reach the
mainline (-next) soon. So let's skip this for now.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [wireless-regdb] Update to wireless-regdb about Italy
From: Seth Forshee @ 2019-07-16 21:01 UTC (permalink / raw)
To: gb; +Cc: linux-wireless, wireless-regdb
In-Reply-To: <8c7c0973-b1c9-0032-1819-e868855b896f@inrete.it>
On Sat, Jul 13, 2019 at 07:10:37PM +0200, gb@inrete.it wrote:
> Hi
>
> I'm Italian and I work in Italy, I realize that nowadays the regdb entry for
> Italy is as follows:
>
> country IT: DFS-ETSI
> (2402 - 2482 @ 40), (20)
> (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
> (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
> (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
> # 60 GHz band channels 1-4, ref: Etsi En 302 567
> (57000 - 66000 @ 2160), (40)
>
> And it misses the lines:
>
> # Short Range Devices (SRD) (ETSI EN 300 440)
> (5725 - 5875 @ 80), (25 mW)
>
> Common to may European Countries.
>
> I dug a bit in the current Italian regulation that is online on the website
> of the
> Ministry of Economic Development: https://www.mise.gov.it/index.php/en/
>
> In the section about the "National Plan of Frequencies" (only in Italian) at
> the URL:
>
> https://www.mise.gov.it/index.php/it/comunicazioni/radio/pnrf-piano-nazionale-di-ripartizione-delle-frequenze
>
>
> Two PDF files are linked:
>
> --Tabelle di attribuzione Tabella B (27,50 MHz – 10.000 MHz) (pdf)
> https://www.mise.gov.it/images/stories/documenti/Tabella_B_2750_MHz-10000_Mhz.pdf
>
> Which at page 28 allows the use for ISM according to the general European
> legislation: 2006/771/CE ERC/REC 70-03
>
> --Note (esplicative, di carattere tecnico e con attribuzioni in deroga al
> piano) (pdf)
> https://www.mise.gov.it/images/stories/documenti/NOTE-pnrf.pdf
> Which at page 334, in the paragraph 3.2.3 states in a explicit way the
> permit to operate the in the band 5.725 ÷ 5.875 MHz,
> with SRD and max power at 25 mW.
>
> According to this regulation there's no reason not to have the:
> (5725 - 5875 @ 80), (25 mW)
> Inserted for Italy in the regdb
>
> Who can do it ?
The page/section numbers you gave for the second document don't
correspond to what I'm seeing, but it does look like you are right that
the entry can be added to the regdb. Anyone can send patches for the
regdb, so if you know how to do that please feel free to do so.
Otherwise let me know and I can prepare a patch.
Thanks,
Seth
^ permalink raw reply
* Re: [PATCH -next] iwlwifi: dbg: work around clang bug by marking debug strings static
From: Nick Desaulniers @ 2019-07-16 17:28 UTC (permalink / raw)
To: Joe Perches, Kalle Valo
Cc: Arnd Bergmann, Nathan Chancellor, Johannes Berg,
Emmanuel Grumbach, Luca Coelho, Intel Linux Wireless,
David S. Miller, Shahar S Matityahu, Sara Sharon, linux-wireless,
netdev, LKML, clang-built-linux
In-Reply-To: <b219cf41933b2f965572af515cf9d3119293bfba.camel@perches.com>
On Thu, Jul 11, 2019 at 7:15 PM Joe Perches <joe@perches.com> wrote:
>
> On Thu, 2019-07-11 at 17:17 -0700, Nick Desaulniers wrote:
> > Commit r353569 in prerelease Clang-9 is producing a linkage failure:
> >
> > ld: drivers/net/wireless/intel/iwlwifi/fw/dbg.o:
> > in function `_iwl_fw_dbg_apply_point':
> > dbg.c:(.text+0x827a): undefined reference to `__compiletime_assert_2387'
> >
> > when the following configs are enabled:
> > - CONFIG_IWLWIFI
> > - CONFIG_IWLMVM
> > - CONFIG_KASAN
> >
> > Work around the issue for now by marking the debug strings as `static`,
> > which they probably should be any ways.
> >
> > Link: https://bugs.llvm.org/show_bug.cgi?id=42580
> > Link: https://github.com/ClangBuiltLinux/linux/issues/580
> > Reported-by: Arnd Bergmann <arnd@arndb.de>
> > Reported-by: Nathan Chancellor <natechancellor@gmail.com>
> > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> > ---
> > drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
> > index e411ac98290d..f8c90ea4e9b4 100644
> > --- a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
> > +++ b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
> > @@ -2438,7 +2438,7 @@ static void iwl_fw_dbg_info_apply(struct iwl_fw_runtime *fwrt,
> > {
> > u32 img_name_len = le32_to_cpu(dbg_info->img_name_len);
> > u32 dbg_cfg_name_len = le32_to_cpu(dbg_info->dbg_cfg_name_len);
> > - const char err_str[] =
> > + static const char err_str[] =
> > "WRT: ext=%d. Invalid %s name length %d, expected %d\n";
>
> Better still would be to use the format string directly
> in both locations instead of trying to deduplicate it
> via storing it into a separate pointer.
>
> Let the compiler/linker consolidate the format.
> It's smaller object code, allows format/argument verification,
> and is simpler for humans to understand.
Whichever Kalle prefers, I just want my CI green again.
>
> ---
> diff --git a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
> index e411ac98290d..25e6712932b8 100644
> --- a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
> +++ b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
> @@ -2438,17 +2438,17 @@ static void iwl_fw_dbg_info_apply(struct iwl_fw_runtime *fwrt,
> {
> u32 img_name_len = le32_to_cpu(dbg_info->img_name_len);
> u32 dbg_cfg_name_len = le32_to_cpu(dbg_info->dbg_cfg_name_len);
> - const char err_str[] =
> - "WRT: ext=%d. Invalid %s name length %d, expected %d\n";
>
> if (img_name_len != IWL_FW_INI_MAX_IMG_NAME_LEN) {
> - IWL_WARN(fwrt, err_str, ext, "image", img_name_len,
> + IWL_WARN(fwrt, "WRT: ext=%d. Invalid %s name length %d, expected %d\n",
> + ext, "image", img_name_len,
> IWL_FW_INI_MAX_IMG_NAME_LEN);
> return;
> }
>
> if (dbg_cfg_name_len != IWL_FW_INI_MAX_DBG_CFG_NAME_LEN) {
> - IWL_WARN(fwrt, err_str, ext, "debug cfg", dbg_cfg_name_len,
> + IWL_WARN(fwrt, "WRT: ext=%d. Invalid %s name length %d, expected %d\n",
> + ext, "debug cfg", dbg_cfg_name_len,
> IWL_FW_INI_MAX_DBG_CFG_NAME_LEN);
> return;
> }
> @@ -2775,8 +2775,6 @@ static void _iwl_fw_dbg_apply_point(struct iwl_fw_runtime *fwrt,
> struct iwl_ucode_tlv *tlv = iter;
> void *ini_tlv = (void *)tlv->data;
> u32 type = le32_to_cpu(tlv->type);
> - const char invalid_ap_str[] =
> - "WRT: ext=%d. Invalid apply point %d for %s\n";
>
> switch (type) {
> case IWL_UCODE_TLV_TYPE_DEBUG_INFO:
> @@ -2786,8 +2784,8 @@ static void _iwl_fw_dbg_apply_point(struct iwl_fw_runtime *fwrt,
> struct iwl_fw_ini_allocation_data *buf_alloc = ini_tlv;
>
> if (pnt != IWL_FW_INI_APPLY_EARLY) {
> - IWL_ERR(fwrt, invalid_ap_str, ext, pnt,
> - "buffer allocation");
> + IWL_ERR(fwrt, "WRT: ext=%d. Invalid apply point %d for %s\n",
> + ext, pnt, "buffer allocation");
> goto next;
> }
>
> @@ -2797,8 +2795,8 @@ static void _iwl_fw_dbg_apply_point(struct iwl_fw_runtime *fwrt,
> }
> case IWL_UCODE_TLV_TYPE_HCMD:
> if (pnt < IWL_FW_INI_APPLY_AFTER_ALIVE) {
> - IWL_ERR(fwrt, invalid_ap_str, ext, pnt,
> - "host command");
> + IWL_ERR(fwrt, "WRT: ext=%d. Invalid apply point %d for %s\n",
> + ext, pnt, "host command");
> goto next;
> }
> iwl_fw_dbg_send_hcmd(fwrt, tlv, ext);
>
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* [PATCH 0/2] mmc: core: Fix Marvell WiFi reset by adding SDIO API to replug card
From: Douglas Anderson @ 2019-07-16 16:42 UTC (permalink / raw)
To: Ulf Hansson, Kalle Valo, Adrian Hunter
Cc: Ganapathi Bhat, linux-wireless, Brian Norris, Amitkumar Karwar,
linux-rockchip, Wolfram Sang, Nishant Sarmukadam, netdev,
Avri Altman, linux-mmc, davem, Xinming Hu, Douglas Anderson,
Jiong Wu, Ritesh Harjani, linux-kernel, Thomas Gleixner,
Greg Kroah-Hartman, Niklas Söderlund
As talked about in the thread at:
http://lkml.kernel.org/r/CAD=FV=X7P2F1k_zwHc0mbtfk55-rucTz_GoDH=PL6zWqKYcpuw@mail.gmail.com
...when the Marvell WiFi card tries to reset itself it kills
Bluetooth. It was observed that we could re-init the card properly by
unbinding / rebinding the host controller. It was also observed that
in the downstream Chrome OS codebase the solution used was
mmc_remove_host() / mmc_add_host(), which is similar to the solution
in this series.
So far I've only done testing of this series using the reset test
source that can be simulated via sysfs. Specifically I ran this test:
for i in $(seq 1000); do
echo "LOOP $i --------"
echo 1 > /sys/kernel/debug/mwifiex/mlan0/reset
while true; do
if ! ping -w15 -c1 "${GW}" >/dev/null 2>&1; then
fail=$(( fail + 1 ))
echo "Fail WiFi ${fail}"
if [[ ${fail} == 3 ]]; then
exit 1
fi
else
fail=0
break
fi
done
hciconfig hci0 down
sleep 1
if ! hciconfig hci0 up; then
echo "Fail BT"
exit 1
fi
done
I ran this several times and got several hundred iterations each
before a failure. When I saw failures:
* Once I saw a "Fail BT"; manually resetting the card again fixed it.
I didn't give it time to see if it would have detected this
automatically.
* Once I saw the ping fail because (for some reason) my device only
got an IPv6 address from my router and the IPv4 ping failed. I
changed my script to use 'ping6' to see if that would help.
* Once I saw the ping fail because the higher level network stack
("shill" in my case) seemed to crash. A few minutes later the
system recovered itself automatically. https://crbug.com/984593 if
you want more details.
* Sometimes while I was testing I saw "Fail WiFi 1" indicating a
transitory failure. Usually this was an association failure, but in
one case I saw the device do "Firmware wakeup failed" after I
triggered the reset. This caused the driver to trigger a re-reset
of itself which eventually recovered things. This was good because
it was an actual test of the normal reset flow (not the one
triggered via sysfs).
Douglas Anderson (2):
mmc: core: Add sdio_trigger_replug() API
mwifiex: Make use of the new sdio_trigger_replug() API to reset
drivers/mmc/core/core.c | 28 +++++++++++++++++++--
drivers/mmc/core/sdio_io.c | 20 +++++++++++++++
drivers/net/wireless/marvell/mwifiex/sdio.c | 14 +++--------
include/linux/mmc/host.h | 15 ++++++++++-
include/linux/mmc/sdio_func.h | 2 ++
5 files changed, 65 insertions(+), 14 deletions(-)
--
2.22.0.510.g264f2c817a-goog
^ permalink raw reply
* [PATCH 1/2] mmc: core: Add sdio_trigger_replug() API
From: Douglas Anderson @ 2019-07-16 16:42 UTC (permalink / raw)
To: Ulf Hansson, Kalle Valo, Adrian Hunter
Cc: Ganapathi Bhat, linux-wireless, Brian Norris, Amitkumar Karwar,
linux-rockchip, Wolfram Sang, Nishant Sarmukadam, netdev,
Avri Altman, linux-mmc, davem, Xinming Hu, Douglas Anderson,
Jiong Wu, Ritesh Harjani, linux-kernel, Thomas Gleixner,
Greg Kroah-Hartman, Niklas Söderlund
In-Reply-To: <20190716164209.62320-1-dianders@chromium.org>
When using Marvell WiFi SDIO cards, it is not uncommon for Linux WiFi
driver to fully lose the communication channel to the firmware running
on the card. Presumably the firmware on the card has a bug or two in
it and occasionally crashes.
The Marvell WiFi driver attempts to recover from this problem.
Specifically the driver has the function mwifiex_sdio_card_reset()
which is called when communcation problems are found. That function
attempts to reset the state of things by utilizing the mmc_hw_reset()
function.
The current solution is a bit complex because the Marvell WiFi driver
needs to manually deinit and reinit the WiFi driver around the reset
call. This means it's going through a bunch of code paths that aren't
normally tested. However, complexity isn't our only problem. The
other (bigger) problem is that Marvell WiFi cards are often combo
WiFi/Bluetooth cards and Bluetooth runs on a second SDIO func. While
the WiFi driver knows that it should re-init its own state around the
mmc_hw_reset() call there is no good way to inform the Bluetooth
driver. That means that in Linux today when you reset the Marvell
WiFi driver you lose all Bluetooth communication. Doh!
One way to fix the above problems is to leverage a more standard way
to reset the Marvell WiFi card where we go through the same code paths
as card unplug and the card plug. In this patch we introduce a new
API call for doing just that: sdio_trigger_replug(). This API call
will trigger an unplug of the SDIO card followed by a plug of the
card. As part of this the card will be nicely reset.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/mmc/core/core.c | 28 ++++++++++++++++++++++++++--
drivers/mmc/core/sdio_io.c | 20 ++++++++++++++++++++
include/linux/mmc/host.h | 15 ++++++++++++++-
include/linux/mmc/sdio_func.h | 2 ++
4 files changed, 62 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 9020cb2490f7..48a7d23aed26 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2164,6 +2164,12 @@ int mmc_sw_reset(struct mmc_host *host)
}
EXPORT_SYMBOL(mmc_sw_reset);
+void mmc_trigger_replug(struct mmc_host *host)
+{
+ host->trigger_replug_state = MMC_REPLUG_STATE_UNPLUG;
+ _mmc_detect_change(host, 0, false);
+}
+
static int mmc_rescan_try_freq(struct mmc_host *host, unsigned freq)
{
host->f_init = freq;
@@ -2217,6 +2223,11 @@ int _mmc_detect_card_removed(struct mmc_host *host)
if (!host->card || mmc_card_removed(host->card))
return 1;
+ if (host->trigger_replug_state == MMC_REPLUG_STATE_UNPLUG) {
+ mmc_card_set_removed(host->card);
+ return 1;
+ }
+
ret = host->bus_ops->alive(host);
/*
@@ -2329,8 +2340,21 @@ void mmc_rescan(struct work_struct *work)
mmc_bus_put(host);
mmc_claim_host(host);
- if (mmc_card_is_removable(host) && host->ops->get_cd &&
- host->ops->get_cd(host) == 0) {
+
+ /*
+ * Move through the state machine if we're triggering an unplug
+ * followed by a re-plug.
+ */
+ if (host->trigger_replug_state == MMC_REPLUG_STATE_UNPLUG) {
+ host->trigger_replug_state = MMC_REPLUG_STATE_PLUG;
+ _mmc_detect_change(host, 0, false);
+ } else if (host->trigger_replug_state == MMC_REPLUG_STATE_PLUG) {
+ host->trigger_replug_state = MMC_REPLUG_STATE_NONE;
+ }
+
+ if (host->trigger_replug_state == MMC_REPLUG_STATE_PLUG ||
+ (mmc_card_is_removable(host) && host->ops->get_cd &&
+ host->ops->get_cd(host) == 0)) {
mmc_power_off(host);
mmc_release_host(host);
goto out;
diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
index 2ba00acf64e6..1c5c2a3ebe5e 100644
--- a/drivers/mmc/core/sdio_io.c
+++ b/drivers/mmc/core/sdio_io.c
@@ -811,3 +811,23 @@ void sdio_retune_release(struct sdio_func *func)
mmc_retune_release(func->card->host);
}
EXPORT_SYMBOL_GPL(sdio_retune_release);
+
+/**
+ * sdio_trigger_replug - trigger an "unplug" + "plug" of the card
+ * @func: SDIO function attached to host
+ *
+ * When you call this function we will schedule events that will
+ * make it look like the card contining the given SDIO func was
+ * unplugged and then re-plugged-in. This is as close as possible
+ * to a full reset of the card that can be achieved.
+ *
+ * NOTE: routnine will temporarily make the card look as if it is
+ * removable even if it is marked non-removable.
+ *
+ * This function should be called while the host is claimed.
+ */
+void sdio_trigger_replug(struct sdio_func *func)
+{
+ mmc_trigger_replug(func->card->host);
+}
+EXPORT_SYMBOL(sdio_trigger_replug);
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index a9b12322c775..e0d41a1bcf17 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -410,6 +410,12 @@ struct mmc_host {
bool trigger_card_event; /* card_event necessary */
+ /* state machine for triggering unplug/replug */
+#define MMC_REPLUG_STATE_NONE 0 /* not doing unplug/replug */
+#define MMC_REPLUG_STATE_UNPLUG 1 /* do unplug next */
+#define MMC_REPLUG_STATE_PLUG 2 /* do plug next */
+ u8 trigger_replug_state;
+
struct mmc_card *card; /* device attached to this host */
wait_queue_head_t wq;
@@ -530,7 +536,12 @@ int mmc_regulator_get_supply(struct mmc_host *mmc);
static inline int mmc_card_is_removable(struct mmc_host *host)
{
- return !(host->caps & MMC_CAP_NONREMOVABLE);
+ /*
+ * A non-removable card briefly looks removable if code has forced
+ * a re-plug of the card.
+ */
+ return host->trigger_replug_state != MMC_REPLUG_STATE_NONE ||
+ !(host->caps & MMC_CAP_NONREMOVABLE);
}
static inline int mmc_card_keep_power(struct mmc_host *host)
@@ -583,4 +594,6 @@ static inline enum dma_data_direction mmc_get_dma_dir(struct mmc_data *data)
int mmc_send_tuning(struct mmc_host *host, u32 opcode, int *cmd_error);
int mmc_abort_tuning(struct mmc_host *host, u32 opcode);
+void mmc_trigger_replug(struct mmc_host *host);
+
#endif /* LINUX_MMC_HOST_H */
diff --git a/include/linux/mmc/sdio_func.h b/include/linux/mmc/sdio_func.h
index 5a177f7a83c3..0d6c73768ae3 100644
--- a/include/linux/mmc/sdio_func.h
+++ b/include/linux/mmc/sdio_func.h
@@ -173,4 +173,6 @@ extern void sdio_retune_crc_enable(struct sdio_func *func);
extern void sdio_retune_hold_now(struct sdio_func *func);
extern void sdio_retune_release(struct sdio_func *func);
+extern void sdio_trigger_replug(struct sdio_func *func);
+
#endif /* LINUX_MMC_SDIO_FUNC_H */
--
2.22.0.510.g264f2c817a-goog
^ permalink raw reply related
* [PATCH 2/2] mwifiex: Make use of the new sdio_trigger_replug() API to reset
From: Douglas Anderson @ 2019-07-16 16:42 UTC (permalink / raw)
To: Ulf Hansson, Kalle Valo, Adrian Hunter
Cc: Ganapathi Bhat, linux-wireless, Brian Norris, Amitkumar Karwar,
linux-rockchip, Wolfram Sang, Nishant Sarmukadam, netdev,
Avri Altman, linux-mmc, davem, Xinming Hu, Douglas Anderson,
linux-kernel
In-Reply-To: <20190716164209.62320-1-dianders@chromium.org>
As described in the patch ("mmc: core: Add sdio_trigger_replug()
API"), the current mwifiex_sdio_card_reset() is broken in the cases
where we're running Bluetooth on a second SDIO func on the same card
as WiFi. The problem goes away if we just use the
sdio_trigger_replug() API call.
NOTE: Even though with this new solution there is less of a reason to
do our work from a workqueue (the unplug / plug mechanism we're using
is possible for a human to perform at any time so the stack is
supposed to handle it without it needing to be called from a special
context), we still need a workqueue because the Marvell reset function
could called from a context where sleeping is invalid and thus we
can't claim the host. One example is Marvell's wakeup_timer_fn().
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 14 +++-----------
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 24c041dad9f6..f77ad2615f08 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -2218,14 +2218,6 @@ static void mwifiex_sdio_card_reset_work(struct mwifiex_adapter *adapter)
{
struct sdio_mmc_card *card = adapter->card;
struct sdio_func *func = card->func;
- int ret;
-
- mwifiex_shutdown_sw(adapter);
-
- /* power cycle the adapter */
- sdio_claim_host(func);
- mmc_hw_reset(func->card->host);
- sdio_release_host(func);
/* Previous save_adapter won't be valid after this. We will cancel
* pending work requests.
@@ -2233,9 +2225,9 @@ static void mwifiex_sdio_card_reset_work(struct mwifiex_adapter *adapter)
clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &card->work_flags);
clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &card->work_flags);
- ret = mwifiex_reinit_sw(adapter);
- if (ret)
- dev_err(&func->dev, "reinit failed: %d\n", ret);
+ sdio_claim_host(func);
+ sdio_trigger_replug(func);
+ sdio_release_host(func);
}
/* This function read/write firmware */
--
2.22.0.510.g264f2c817a-goog
^ permalink raw reply related
* [PATCH v2] libertas_tf: Use correct channel range in lbtf_geo_init
From: YueHaibing @ 2019-07-16 14:42 UTC (permalink / raw)
To: kvalo, davem, lkundrak, derosier
Cc: linux-kernel, netdev, linux-wireless, YueHaibing
It seems we should use 'range' instead of 'priv->range'
in lbtf_geo_init(), because 'range' is the corret one
related to current regioncode.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 691cdb49388b ("libertas_tf: command helper functions for libertas_tf")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
v2: fix compile error
---
drivers/net/wireless/marvell/libertas_tf/cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/libertas_tf/cmd.c b/drivers/net/wireless/marvell/libertas_tf/cmd.c
index 1eacca0..a333172 100644
--- a/drivers/net/wireless/marvell/libertas_tf/cmd.c
+++ b/drivers/net/wireless/marvell/libertas_tf/cmd.c
@@ -65,7 +65,7 @@ static void lbtf_geo_init(struct lbtf_private *priv)
break;
}
- for (ch = priv->range.start; ch < priv->range.end; ch++)
+ for (ch = range->start; ch < range->end; ch++)
priv->channels[CHAN_TO_IDX(ch)].flags = 0;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] libertas_tf: Use correct channel range in lbtf_geo_init
From: Yuehaibing @ 2019-07-16 13:38 UTC (permalink / raw)
To: kvalo, davem, lkundrak, derosier; +Cc: linux-kernel, netdev, linux-wireless
In-Reply-To: <20190716132534.11256-1-yuehaibing@huawei.com>
Pls ignore this, sorry
On 2019/7/16 21:25, YueHaibing wrote:
> It seems we should use 'range' instead of 'priv->range'
> in lbtf_geo_init(), because 'range' is the corret one
> related to current regioncode.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: 691cdb49388b ("libertas_tf: command helper functions for libertas_tf")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/wireless/marvell/libertas_tf/cmd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/libertas_tf/cmd.c b/drivers/net/wireless/marvell/libertas_tf/cmd.c
> index 1eacca0..a333172 100644
> --- a/drivers/net/wireless/marvell/libertas_tf/cmd.c
> +++ b/drivers/net/wireless/marvell/libertas_tf/cmd.c
> @@ -65,7 +65,7 @@ static void lbtf_geo_init(struct lbtf_private *priv)
> break;
> }
>
> - for (ch = priv->range.start; ch < priv->range.end; ch++)
> + for (ch = range.start; ch < range.end; ch++)
> priv->channels[CHAN_TO_IDX(ch)].flags = 0;
> }
>
>
^ permalink raw reply
* [PATCH] libertas_tf: Use correct channel range in lbtf_geo_init
From: YueHaibing @ 2019-07-16 13:25 UTC (permalink / raw)
To: kvalo, davem, lkundrak, derosier
Cc: linux-kernel, netdev, linux-wireless, YueHaibing
It seems we should use 'range' instead of 'priv->range'
in lbtf_geo_init(), because 'range' is the corret one
related to current regioncode.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 691cdb49388b ("libertas_tf: command helper functions for libertas_tf")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/marvell/libertas_tf/cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/libertas_tf/cmd.c b/drivers/net/wireless/marvell/libertas_tf/cmd.c
index 1eacca0..a333172 100644
--- a/drivers/net/wireless/marvell/libertas_tf/cmd.c
+++ b/drivers/net/wireless/marvell/libertas_tf/cmd.c
@@ -65,7 +65,7 @@ static void lbtf_geo_init(struct lbtf_private *priv)
break;
}
- for (ch = priv->range.start; ch < priv->range.end; ch++)
+ for (ch = range.start; ch < range.end; ch++)
priv->channels[CHAN_TO_IDX(ch)].flags = 0;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 20/24] wireless: Remove call to memset after dma_alloc_coherent
From: Kalle Valo @ 2019-07-16 12:44 UTC (permalink / raw)
To: Fuqian Huang; +Cc: linux-wireless
In-Reply-To: <CABXRUiR0XAB8x9MkF=UH1KTojWDovEy9hGaUEuZnAhbfCAcD3w@mail.gmail.com>
(adding back linux-wireless, please don't drop CC)
> Kalle Valo <kvalo@codeaurora.org> 於 2019年7月15日週一 下午5:07寫道：
>>
>> Fuqian Huang <huangfq.daxian@gmail.com> writes:
>>
>> > In commit 518a2f1925c3
>> > ("dma-mapping: zero memory returned from dma_alloc_*"),
>> > dma_alloc_coherent has already zeroed the memory.
>> > So memset is not needed.
>> >
>> > Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
>> > ---
>> > Changes in v3:
>> > - Use actual commit rather than the merge commit in the commit message
>> >
>> > drivers/net/wireless/ath/ath10k/ce.c | 5 -----
>> > drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 --
>> > drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c | 2 --
>> > drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c | 2 --
>> > 4 files changed, 11 deletions(-)
>>
>> Via which tree is this supposed to go? Can I take this to
>> wireless-drivers-next?
>
> I think the wireless-drivers-next is fine.
Good, I'll then take these to my queue.
> The four file have similar changes. And they are both under wireless
> subsystem. How should i indicate which tree the patch should go to?
> Should I mark them in [patch v3 wireless] or after the Changes in v3?
> I should avoid this mistake next time.
As there's no dependency between patches to me the easiest is that you
send the wireless patches separately, that way I can take them directly
without asking anything, and not worry about dependencies or if someone
else is going to apply them. For example Colin King does that his
cleanup patches and I like it a lot.
But if I see patch 20/24 (and only that, no cover letter or over
patches) I have no clue what the plan is and need extra effort to
understand what I should do.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] mt76: mt76x0u: add support to TP-Link T2UHP
From: Kalle Valo @ 2019-07-16 11:11 UTC (permalink / raw)
To: Sid Hayn
Cc: Lorenzo Bianconi, Felix Fietkau, Lorenzo Bianconi, linux-wireless,
Stanislaw Gruszka
In-Reply-To: <CAM0KTbBU7-BTTR_R9b7VNQuqRpd=rMk8nAQANQ7shns+XGahdw@mail.gmail.com>
Sid Hayn <sidhayn@gmail.com> writes:
> I saw you accept this patch, thanks. Any chance of pushing this
> simple fix in 5.1.x and 5.2.x? I've tested and confirmed this
> hardware works fine.
Actually you can ask that yourself:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
Especially check option 2.
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH 09/11] rtw88: remove all RTW_MAX_POWER_INDEX macro
From: Tony Chuang @ 2019-07-16 8:15 UTC (permalink / raw)
To: Brian Norris; +Cc: Kalle Valo, linux-wireless
In-Reply-To: <CA+ASDXMWYhORB7=bCh84BO1wuPdAa7dpTSyTWuUYzanfTYA=Pw@mail.gmail.com>
> Subject: Re: [PATCH 09/11] rtw88: remove all RTW_MAX_POWER_INDEX
> macro
>
> I realize this is already upstream, but I thought I'd ask here, since
> I was going back and reviewing some of this:
>
> On Wed, May 29, 2019 at 12:55 AM <yhchuang@realtek.com> wrote:
> >
> > From: Tzu-En Huang <tehuang@realtek.com>
> >
> > Since this macro definition has different values in different chipset,
> > the current defined macro value is for 8822b. This will cause the
> > settings of 8822c be incorrect.
>
> ^^ Is this actually correct, that 8822b was correct and 8822c was
> wrong? Because I see RTW_MAX_POWER_INDEX used to be defined as 0x7f,
> and rtw8822c_hw_spec.max_power_index also appears to be 0x7f. Which
> would sound like 8822b (*b*, not c) was wrong, as it lists 0x3f.
>
> Anyway, I'm going to assume you got the change right, and you just
> mis-spoke in the description.
Yes, I think he just mis-spoke it, and the code is right.
Thanks
Yan-Hsuan
^ permalink raw reply
* [PATCH v2] rtw88: debug: dump tx power indexes in use
From: yhchuang @ 2019-07-16 5:28 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, briannorris
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.
Also this patch fixes unused function warning.
Fixes: b741422218ef ("rtw88: refine flow to get tx power index")
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
---
v1 -> v2
refine seq_printf format from such as
"%5s%-5s", "CCK_", cck_rate[idx]
to
" CCK_%-5s", cck_rate[idx]
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..383b04c 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, " 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, " OFDM_%-4s", ofdm_rate[idx]);
+}
+
+static void rtw_print_ht_rate_txt(struct seq_file *m, u8 rate)
+{
+ u8 mcs_n = rate - DESC_RATEMCS0;
+
+ seq_printf(m, " MCS%-6u", mcs_n);
+}
+
+static void rtw_print_vht_rate_txt(struct seq_file *m, u8 rate)
+{
+ u8 idx = rate - DESC_RATEVHT1SS_MCS0;
+ u8 n_ss, mcs_n;
+
+ /* n spatial stream */
+ n_ss = 1 + idx / 10;
+ /* MCS n */
+ mcs_n = idx % 10;
+ seq_printf(m, " VHT%uSMCS%u", n_ss, mcs_n);
+}
+
+static int rtw_debugfs_get_tx_pwr_tbl(struct seq_file *m, void *v)
+{
+ struct rtw_debugfs_priv *debugfs_priv = m->private;
+ struct rtw_dev *rtwdev = debugfs_priv->rtwdev;
+ struct rtw_hal *hal = &rtwdev->hal;
+ void (*print_rate)(struct seq_file *, u8) = NULL;
+ u8 path, rate;
+ struct rtw_power_params pwr_param = {0};
+ u8 bw = hal->current_band_width;
+ u8 ch = hal->current_channel;
+ u8 regd = rtwdev->regd.txpwr_regd;
+
+ seq_printf(m, "%-4s %-10s %-3s%6s %-4s %4s (%-4s %-4s)\n",
+ "path", "rate", "pwr", "", "base", "", "byr", "lmt");
+
+ mutex_lock(&hal->tx_power_mutex);
+ for (path = RF_PATH_A; path <= RF_PATH_B; path++) {
+ /* there is no CCK rates used in 5G */
+ if (hal->current_band_type == RTW_BAND_5G)
+ rate = DESC_RATE6M;
+ else
+ rate = DESC_RATE1M;
+
+ /* now, not support vht 3ss and vht 4ss*/
+ for (; rate <= DESC_RATEVHT2SS_MCS9; rate++) {
+ /* now, not support ht 3ss and ht 4ss*/
+ if (rate > DESC_RATEMCS15 &&
+ rate < DESC_RATEVHT1SS_MCS0)
+ continue;
+
+ switch (rate) {
+ case DESC_RATE1M...DESC_RATE11M:
+ print_rate = rtw_print_cck_rate_txt;
+ break;
+ case DESC_RATE6M...DESC_RATE54M:
+ print_rate = rtw_print_ofdm_rate_txt;
+ break;
+ case DESC_RATEMCS0...DESC_RATEMCS15:
+ print_rate = rtw_print_ht_rate_txt;
+ break;
+ case DESC_RATEVHT1SS_MCS0...DESC_RATEVHT2SS_MCS9:
+ print_rate = rtw_print_vht_rate_txt;
+ break;
+ default:
+ print_rate = NULL;
+ break;
+ }
+
+ rtw_get_tx_power_params(rtwdev, path, rate, bw,
+ ch, regd, &pwr_param);
+
+ seq_printf(m, "%4c ", path + 'A');
+ if (print_rate)
+ print_rate(m, rate);
+ seq_printf(m, " %3u(0x%02x) %4u %4d (%4d %4d)\n",
+ hal->tx_pwr_tbl[path][rate],
+ hal->tx_pwr_tbl[path][rate],
+ pwr_param.pwr_base,
+ min_t(s8, pwr_param.pwr_offset,
+ pwr_param.pwr_limit),
+ pwr_param.pwr_offset, pwr_param.pwr_limit);
+ }
+ }
+
+ mutex_unlock(&hal->tx_power_mutex);
+
+ return 0;
+}
+
#define rtw_debug_impl_mac(page, addr) \
static struct rtw_debugfs_priv rtw_debug_priv_mac_ ##page = { \
.cb_read = rtw_debug_get_mac_page, \
@@ -514,6 +621,10 @@ static struct rtw_debugfs_priv rtw_debug_priv_rf_dump = {
.cb_read = rtw_debug_get_rf_dump,
};
+static struct rtw_debugfs_priv rtw_debug_priv_tx_pwr_tbl = {
+ .cb_read = rtw_debugfs_get_tx_pwr_tbl,
+};
+
static struct rtw_debugfs_priv rtw_debug_priv_write_reg = {
.cb_write = rtw_debugfs_set_write_reg,
};
@@ -610,6 +721,7 @@ void rtw_debugfs_init(struct rtw_dev *rtwdev)
rtw_debugfs_add_r(bb_41);
}
rtw_debugfs_add_r(rf_dump);
+ rtw_debugfs_add_r(tx_pwr_tbl);
}
#endif /* CONFIG_RTW88_DEBUGFS */
--
2.7.4
^ permalink raw reply related
* [PATCH v2] mac80211: add IEEE80211_KEY_FLAG_GENERATE_MMIE to ieee80211_key_flags
From: Lorenzo Bianconi @ 2019-07-15 22:09 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, nbd
Add IEEE80211_KEY_FLAG_GENERATE_MMIE flag to ieee80211_key_flags in order
to allow the driver to notify mac80211 to generate MMIE and that it
requires sequence number generation only.
This is a preliminary patch to add BIP_CMAC_128 hw support to mt7615
driver
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes since v1:
- rename IEEE80211_KEY_FLAG_PUT_MMIE_SPACE in IEEE80211_KEY_FLAG_GENERATE_MMIE
---
include/net/mac80211.h | 4 ++++
net/mac80211/wpa.c | 6 +++++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d26da013f7c0..a655de2c65dd 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1702,6 +1702,9 @@ struct wireless_dev *ieee80211_vif_to_wdev(struct ieee80211_vif *vif);
* a TKIP key if it only requires MIC space. Do not set together with
* @IEEE80211_KEY_FLAG_GENERATE_MMIC on the same key.
* @IEEE80211_KEY_FLAG_NO_AUTO_TX: Key needs explicit Tx activation.
+ * @IEEE80211_KEY_FLAG_GENERATE_MMIE: This flag should be set by the driver
+ * for a AES_CMAC key to indicate that it requires sequence number
+ * generation only
*/
enum ieee80211_key_flags {
IEEE80211_KEY_FLAG_GENERATE_IV_MGMT = BIT(0),
@@ -1714,6 +1717,7 @@ enum ieee80211_key_flags {
IEEE80211_KEY_FLAG_RESERVE_TAILROOM = BIT(7),
IEEE80211_KEY_FLAG_PUT_MIC_SPACE = BIT(8),
IEEE80211_KEY_FLAG_NO_AUTO_TX = BIT(9),
+ IEEE80211_KEY_FLAG_GENERATE_MMIE = BIT(10),
};
/**
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index a51c7909366e..f5845af9a449 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -946,7 +946,8 @@ ieee80211_crypto_aes_cmac_encrypt(struct ieee80211_tx_data *tx)
info = IEEE80211_SKB_CB(skb);
- if (info->control.hw_key)
+ if (info->control.hw_key &&
+ !(key->conf.flags & IEEE80211_KEY_FLAG_GENERATE_MMIE))
return TX_CONTINUE;
if (WARN_ON(skb_tailroom(skb) < sizeof(*mmie)))
@@ -962,6 +963,9 @@ ieee80211_crypto_aes_cmac_encrypt(struct ieee80211_tx_data *tx)
bip_ipn_set64(mmie->sequence_number, pn64);
+ if (info->control.hw_key)
+ return TX_CONTINUE;
+
bip_aad(skb, aad);
/*
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 1/2] rt2x00usb: fix rx queue hang
From: Kalle Valo @ 2019-07-15 17:53 UTC (permalink / raw)
To: Soeren Moch
Cc: Stanislaw Gruszka, Soeren Moch, stable, Helmut Schaa,
David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <20190701105314.9707-1-smoch@web.de>
Soeren Moch <smoch@web.de> wrote:
> Since commit ed194d136769 ("usb: core: remove local_irq_save() around
> ->complete() handler") the handler rt2x00usb_interrupt_rxdone() is
> not running with interrupts disabled anymore. So this completion handler
> is not guaranteed to run completely before workqueue processing starts
> for the same queue entry.
> Be sure to set all other flags in the entry correctly before marking
> this entry ready for workqueue processing. This way we cannot miss error
> conditions that need to be signalled from the completion handler to the
> worker thread.
> Note that rt2x00usb_work_rxdone() processes all available entries, not
> only such for which queue_work() was called.
>
> This patch is similar to what commit df71c9cfceea ("rt2x00: fix order
> of entry flags modification") did for TX processing.
>
> This fixes a regression on a RT5370 based wifi stick in AP mode, which
> suddenly stopped data transmission after some period of heavy load. Also
> stopping the hanging hostapd resulted in the error message "ieee80211
> phy0: rt2x00queue_flush_queue: Warning - Queue 14 failed to flush".
> Other operation modes are probably affected as well, this just was
> the used testcase.
>
> Fixes: ed194d136769 ("usb: core: remove local_irq_save() around ->complete() handler")
> Cc: stable@vger.kernel.org # 4.20+
> Signed-off-by: Soeren Moch <smoch@web.de>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers.git, thanks.
41a531ffa4c5 rt2x00usb: fix rx queue hang
--
https://patchwork.kernel.org/patch/11025561/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: work around uninitialized vht_pfr variable
From: Kalle Valo @ 2019-07-15 17:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Miaoqing Pan, David S. Miller, Rakesh Pillai,
Brian Norris, Balaji Pothunoori, Wen Gong, Pradeep kumar Chitrapu,
Sriram R, ath10k, linux-wireless, netdev, linux-kernel,
clang-built-linux
In-Reply-To: <20190708125050.3689133-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> As clang points out, the vht_pfr is assigned to a struct member
> without being initialized in one case:
>
> drivers/net/wireless/ath/ath10k/mac.c:7528:7: error: variable 'vht_pfr' is used uninitialized whenever 'if' condition
> is false [-Werror,-Wsometimes-uninitialized]
> if (!ath10k_mac_can_set_bitrate_mask(ar, band, mask,
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/wireless/ath/ath10k/mac.c:7551:20: note: uninitialized use occurs here
> arvif->vht_pfr = vht_pfr;
> ^~~~~~~
> drivers/net/wireless/ath/ath10k/mac.c:7528:3: note: remove the 'if' if its condition is always true
> if (!ath10k_mac_can_set_bitrate_mask(ar, band, mask,
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/wireless/ath/ath10k/mac.c:7483:12: note: initialize the variable 'vht_pfr' to silence this warning
> u8 vht_pfr;
>
> Add an explicit but probably incorrect initialization here.
> I suspect we want a better fix here, but chose this approach to
> illustrate the issue.
>
> Fixes: 8b97b055dc9d ("ath10k: fix failure to set multiple fixed rate")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Patch applied to wireless-drivers.git, thanks.
ff414f31ce37 ath10k: work around uninitialized vht_pfr variable
--
https://patchwork.kernel.org/patch/11034993/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/2] iwlwifi: add new cards for 9000 and 20000 series
From: Kalle Valo @ 2019-07-15 17:48 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Ihab Zhaika, stable, Luca Coelho
In-Reply-To: <20190708155534.18241-2-luca@coelho.fi>
Luca Coelho <luca@coelho.fi> wrote:
> From: Ihab Zhaika <ihab.zhaika@intel.com>
>
> add two new PCI ID's for 9000 and 20000 series
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Ihab Zhaika <ihab.zhaika@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2 patches applied to wireless-drivers.git, thanks.
ffcb60a54f24 iwlwifi: add new cards for 9000 and 20000 series
a7d544d63120 iwlwifi: pcie: add support for qu c-step devices
--
https://patchwork.kernel.org/patch/11035359/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtw88: make functions static
From: Brian Norris @ 2019-07-15 17:11 UTC (permalink / raw)
To: Tony Chuang; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <F7CD281DE3E379468C6D07993EA72F84D1867CEE@RTITMBSVM04.realtek.com.tw>
On Sun, Jul 14, 2019 at 7:24 PM Tony Chuang <yhchuang@realtek.com> wrote:
> I am sorry I have to NACK it.
>
> Nothing wrong about this patch. Because in the last patch set I sent has
> 11 patches, but one of them is not applied by Kalle.
> And I am going to resend it, which will use rtw_get_tx_power_params
> in debug.c
I suppose that's fine with me. I've marked it as Rejected in Patchwork.
(Normally, I would say: it's your fault for leaving these things
unused. But it was in the middle of the series, where you were aiming
to start using it by the end.)
It would still be nice to see the promised v2:
https://patchwork.kernel.org/patch/10966403/
Regards,
Brian
^ permalink raw reply
* Re: [PATCH] mt76: mt76x0u: add support to TP-Link T2UHP
From: Sid Hayn @ 2019-07-15 15:38 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Felix Fietkau, Lorenzo Bianconi, linux-wireless,
Stanislaw Gruszka
In-Reply-To: <dfb97adb52811bed530449c22a172724ed992771.1562353065.git.lorenzo@kernel.org>
Felix,
I saw you accept this patch, thanks. Any chance of pushing this
simple fix in 5.1.x and 5.2.x? I've tested and confirmed this
hardware works fine.
Thanks,
Zero
On Fri, Jul 5, 2019 at 3:01 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
>
> Introduce support to TP-Link T2UHP
> https://wikidevi.com/wiki/TP-LINK_Archer_T2UHP
>
> Tested-by: Sid Hayn <sidhayn@gmail.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
> index 627ed1fc7b15..b007bcd2e999 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt76x0/usb.c
> @@ -32,6 +32,7 @@ static struct usb_device_id mt76x0_device_table[] = {
> { USB_DEVICE(0x20f4, 0x806b) }, /* TRENDnet TEW-806UBH */
> { USB_DEVICE(0x7392, 0xc711) }, /* Devolo Wifi ac Stick */
> { USB_DEVICE(0x0df6, 0x0079) }, /* Sitecom Europe B.V. ac Stick */
> + { USB_DEVICE(0x2357, 0x0123) }, /* TP-LINK T2UHP */
> { USB_DEVICE(0x2357, 0x0105),
> .driver_info = 1, }, /* TP-LINK Archer T1U */
> { USB_DEVICE_AND_INTERFACE_INFO(0x0E8D, 0x7630, 0xff, 0x2, 0xff)}, /* MT7630U */
> --
> 2.21.0
>
^ permalink raw reply
* [PATCH AUTOSEL 5.2 002/249] ath10k: htt: don't use txdone_fifo with SDIO
From: Sasha Levin @ 2019-07-15 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alagu Sankar, Wen Gong, Kalle Valo, Sasha Levin, ath10k,
linux-wireless, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Alagu Sankar <alagusankar@silex-india.com>
[ Upstream commit e2a6b711282a371c5153239e0468a48254f17ca6 ]
HTT High Latency (ATH10K_DEV_TYPE_HL) does not use txdone_fifo at all, we don't
even initialise it by skipping ath10k_htt_tx_alloc_buf() in
ath10k_htt_tx_start(). Because of this using QCA6174 SDIO
ath10k_htt_rx_tx_compl_ind() will crash when it accesses unitialised
txdone_fifo. So skip txdone_fifo when using High Latency mode.
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Co-developed-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Alagu Sankar <alagusankar@silex-india.com>
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 1acc622d2183..f22840bbc389 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2277,7 +2277,9 @@ static void ath10k_htt_rx_tx_compl_ind(struct ath10k *ar,
* Note that with only one concurrent reader and one concurrent
* writer, you don't need extra locking to use these macro.
*/
- if (!kfifo_put(&htt->txdone_fifo, tx_done)) {
+ if (ar->bus_param.dev_type == ATH10K_DEV_TYPE_HL) {
+ ath10k_txrx_tx_unref(htt, &tx_done);
+ } else if (!kfifo_put(&htt->txdone_fifo, tx_done)) {
ath10k_warn(ar, "txdone fifo overrun, msdu_id %d status %d\n",
tx_done.msdu_id, tx_done.status);
ath10k_txrx_tx_unref(htt, &tx_done);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 003/249] ath10k: fix incorrect multicast/broadcast rate setting
From: Sasha Levin @ 2019-07-15 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Pradeep kumar Chitrapu, Zhi Chen, Sven Eckelmann, Kalle Valo,
Sasha Levin, ath10k, linux-wireless, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Pradeep kumar Chitrapu <pradeepc@codeaurora.org>
[ Upstream commit 93ee3d108fc77e19efeac3ec5aa7d5886711bfef ]
Invalid rate code is sent to firmware when multicast rate value of 0 is
sent to driver indicating disabled case, causing broken mesh path.
so fix that.
Tested on QCA9984 with firmware 10.4-3.6.1-00827
Sven tested on IPQ4019 with 10.4-3.5.3-00057 and QCA9888 with 10.4-3.5.3-00053
(ath10k-firmware) and 10.4-3.6-00140 (linux-firmware 2018-12-16-211de167).
Fixes: cd93b83ad92 ("ath10k: support for multicast rate control")
Co-developed-by: Zhi Chen <zhichen@codeaurora.org>
Signed-off-by: Zhi Chen <zhichen@codeaurora.org>
Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Tested-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath10k/mac.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 9c703d287333..e8997e22ceec 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5588,8 +5588,8 @@ 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;
- int rateidx, ret = 0, hw_rate_code;
+ u8 rate, basic_rate_idx, rateidx;
+ int ret = 0, hw_rate_code, mcast_rate;
enum nl80211_band band;
const struct ieee80211_supported_band *sband;
@@ -5776,7 +5776,11 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
if (changed & BSS_CHANGED_MCAST_RATE &&
!ath10k_mac_vif_chan(arvif->vif, &def)) {
band = def.chan->band;
- rateidx = vif->bss_conf.mcast_rate[band] - 1;
+ mcast_rate = vif->bss_conf.mcast_rate[band];
+ if (mcast_rate > 0)
+ rateidx = mcast_rate - 1;
+ else
+ rateidx = ffs(vif->bss_conf.basic_rates) - 1;
if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY)
rateidx += ATH10K_MAC_FIRST_OFDM_RATE_IDX;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 004/249] ath9k: Don't trust TX status TID number when reporting airtime
From: Sasha Levin @ 2019-07-15 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Toke Høiland-Jørgensen, Miguel Catalan Cid, Kalle Valo,
Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Toke Høiland-Jørgensen <toke@redhat.com>
[ Upstream commit 389b72e58259336c2d56d58b660b79cf4b9e0dcb ]
As already noted a comment in ath_tx_complete_aggr(), the hardware will
occasionally send a TX status with the wrong tid number. If we trust the
value, airtime usage will be reported to the wrong AC, which can cause the
deficit on that AC to become very low, blocking subsequent attempts to
transmit.
To fix this, account airtime usage to the TID number from the original skb,
instead of the one in the hardware TX status report.
Reported-by: Miguel Catalan Cid <miguel.catalan@i2cat.net>
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index b17e1ca40995..3be0aeedb9b5 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -668,7 +668,8 @@ static bool bf_is_ampdu_not_probing(struct ath_buf *bf)
static void ath_tx_count_airtime(struct ath_softc *sc,
struct ieee80211_sta *sta,
struct ath_buf *bf,
- struct ath_tx_status *ts)
+ struct ath_tx_status *ts,
+ u8 tid)
{
u32 airtime = 0;
int i;
@@ -679,7 +680,7 @@ static void ath_tx_count_airtime(struct ath_softc *sc,
airtime += rate_dur * bf->rates[i].count;
}
- ieee80211_sta_register_airtime(sta, ts->tid, airtime, 0);
+ ieee80211_sta_register_airtime(sta, tid, airtime, 0);
}
static void ath_tx_process_buffer(struct ath_softc *sc, struct ath_txq *txq,
@@ -709,7 +710,7 @@ static void ath_tx_process_buffer(struct ath_softc *sc, struct ath_txq *txq,
if (sta) {
struct ath_node *an = (struct ath_node *)sta->drv_priv;
tid = ath_get_skb_tid(sc, an, bf->bf_mpdu);
- ath_tx_count_airtime(sc, sta, bf, ts);
+ ath_tx_count_airtime(sc, sta, bf, ts, tid->tidno);
if (ts->ts_status & (ATH9K_TXERR_FILT | ATH9K_TXERR_XRETRY))
tid->clear_ps_filter = true;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 005/249] wil6210: fix potential out-of-bounds read
From: Sasha Levin @ 2019-07-15 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Gustavo A. R. Silva, Maya Erez, Kalle Valo, Sasha Levin,
linux-wireless, wil6210, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
[ Upstream commit bfabdd6997323adbedccb13a3fed1967fb8cf8f5 ]
Notice that *rc* can evaluate to up to 5, include/linux/netdevice.h:
enum gro_result {
GRO_MERGED,
GRO_MERGED_FREE,
GRO_HELD,
GRO_NORMAL,
GRO_DROP,
GRO_CONSUMED,
};
typedef enum gro_result gro_result_t;
In case *rc* evaluates to 5, we end up having an out-of-bounds read
at drivers/net/wireless/ath/wil6210/txrx.c:821:
wil_dbg_txrx(wil, "Rx complete %d bytes => %s\n",
len, gro_res_str[rc]);
Fix this by adding element "GRO_CONSUMED" to array gro_res_str.
Addresses-Coverity-ID: 1444666 ("Out-of-bounds read")
Fixes: 194b482b5055 ("wil6210: Debug print GRO Rx result")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/wil6210/txrx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/wil6210/txrx.c b/drivers/net/wireless/ath/wil6210/txrx.c
index 4ccfd1404458..d74837cce67f 100644
--- a/drivers/net/wireless/ath/wil6210/txrx.c
+++ b/drivers/net/wireless/ath/wil6210/txrx.c
@@ -750,6 +750,7 @@ void wil_netif_rx_any(struct sk_buff *skb, struct net_device *ndev)
[GRO_HELD] = "GRO_HELD",
[GRO_NORMAL] = "GRO_NORMAL",
[GRO_DROP] = "GRO_DROP",
+ [GRO_CONSUMED] = "GRO_CONSUMED",
};
wil->txrx_ops.get_netif_rx_params(skb, &cid, &security);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 006/249] ath10k: Do not send probe response template for mesh
From: Sasha Levin @ 2019-07-15 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Surabhi Vishnoi, Kalle Valo, Sasha Levin, ath10k, linux-wireless,
netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Surabhi Vishnoi <svishnoi@codeaurora.org>
[ Upstream commit 97354f2c432788e3163134df6bb144f4b6289d87 ]
Currently mac80211 do not support probe response template for
mesh point. When WMI_SERVICE_BEACON_OFFLOAD is enabled, host
driver tries to configure probe response template for mesh, but
it fails because the interface type is not NL80211_IFTYPE_AP but
NL80211_IFTYPE_MESH_POINT.
To avoid this failure, skip sending probe response template to
firmware for mesh point.
Tested HW: WCN3990/QCA6174/QCA9984
Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath10k/mac.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index e8997e22ceec..b500fd427595 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1630,6 +1630,10 @@ static int ath10k_mac_setup_prb_tmpl(struct ath10k_vif *arvif)
if (arvif->vdev_type != WMI_VDEV_TYPE_AP)
return 0;
+ /* For mesh, probe response and beacon share the same template */
+ if (ieee80211_vif_is_mesh(vif))
+ return 0;
+
prb = ieee80211_proberesp_get(hw, vif);
if (!prb) {
ath10k_warn(ar, "failed to get probe resp template from mac80211\n");
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.2 008/249] ath9k: Check for errors when reading SREV register
From: Sasha Levin @ 2019-07-15 13:42 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Tim Schumacher, Kalle Valo, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190715134655.4076-1-sashal@kernel.org>
From: Tim Schumacher <timschumi@gmx.de>
[ Upstream commit 2f90c7e5d09437a4d8d5546feaae9f1cf48cfbe1 ]
Right now, if an error is encountered during the SREV register
read (i.e. an EIO in ath9k_regread()), that error code gets
passed all the way to __ath9k_hw_init(), where it is visible
during the "Chip rev not supported" message.
ath9k_htc 1-1.4:1.0: ath9k_htc: HTC initialized with 33 credits
ath: phy2: Mac Chip Rev 0x0f.3 is not supported by this driver
ath: phy2: Unable to initialize hardware; initialization status: -95
ath: phy2: Unable to initialize hardware; initialization status: -95
ath9k_htc: Failed to initialize the device
Check for -EIO explicitly in ath9k_hw_read_revisions() and return
a boolean based on the success of the operation. Check for that in
__ath9k_hw_init() and abort with a more debugging-friendly message
if reading the revisions wasn't successful.
ath9k_htc 1-1.4:1.0: ath9k_htc: HTC initialized with 33 credits
ath: phy2: Failed to read SREV register
ath: phy2: Could not read hardware revision
ath: phy2: Unable to initialize hardware; initialization status: -95
ath: phy2: Unable to initialize hardware; initialization status: -95
ath9k_htc: Failed to initialize the device
This helps when debugging by directly showing the first point of
failure and it could prevent possible errors if a 0x0f.3 revision
is ever supported.
Signed-off-by: Tim Schumacher <timschumi@gmx.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/ath/ath9k/hw.c | 32 +++++++++++++++++++++--------
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 8581d917635a..b6773d613f0c 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -252,8 +252,9 @@ void ath9k_hw_get_channel_centers(struct ath_hw *ah,
/* Chip Revisions */
/******************/
-static void ath9k_hw_read_revisions(struct ath_hw *ah)
+static bool ath9k_hw_read_revisions(struct ath_hw *ah)
{
+ u32 srev;
u32 val;
if (ah->get_mac_revision)
@@ -269,25 +270,33 @@ static void ath9k_hw_read_revisions(struct ath_hw *ah)
val = REG_READ(ah, AR_SREV);
ah->hw_version.macRev = MS(val, AR_SREV_REVISION2);
}
- return;
+ return true;
case AR9300_DEVID_AR9340:
ah->hw_version.macVersion = AR_SREV_VERSION_9340;
- return;
+ return true;
case AR9300_DEVID_QCA955X:
ah->hw_version.macVersion = AR_SREV_VERSION_9550;
- return;
+ return true;
case AR9300_DEVID_AR953X:
ah->hw_version.macVersion = AR_SREV_VERSION_9531;
- return;
+ return true;
case AR9300_DEVID_QCA956X:
ah->hw_version.macVersion = AR_SREV_VERSION_9561;
- return;
+ return true;
}
- val = REG_READ(ah, AR_SREV) & AR_SREV_ID;
+ srev = REG_READ(ah, AR_SREV);
+
+ if (srev == -EIO) {
+ ath_err(ath9k_hw_common(ah),
+ "Failed to read SREV register");
+ return false;
+ }
+
+ val = srev & AR_SREV_ID;
if (val == 0xFF) {
- val = REG_READ(ah, AR_SREV);
+ val = srev;
ah->hw_version.macVersion =
(val & AR_SREV_VERSION2) >> AR_SREV_TYPE2_S;
ah->hw_version.macRev = MS(val, AR_SREV_REVISION2);
@@ -306,6 +315,8 @@ static void ath9k_hw_read_revisions(struct ath_hw *ah)
if (ah->hw_version.macVersion == AR_SREV_VERSION_5416_PCIE)
ah->is_pciexpress = true;
}
+
+ return true;
}
/************************************/
@@ -559,7 +570,10 @@ static int __ath9k_hw_init(struct ath_hw *ah)
struct ath_common *common = ath9k_hw_common(ah);
int r = 0;
- ath9k_hw_read_revisions(ah);
+ if (!ath9k_hw_read_revisions(ah)) {
+ ath_err(common, "Could not read hardware revisions");
+ return -EOPNOTSUPP;
+ }
switch (ah->hw_version.macVersion) {
case AR_SREV_VERSION_5416_PCI:
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox