* Re: [PATCH 21/27] qtnfmac: extend "IE set" TLV to include frame type info
From: Sergey Matyukevich @ 2017-08-30 12:07 UTC (permalink / raw)
To: igor.mitsyanko.os; +Cc: linux-wireless, avinashp, johannes
In-Reply-To: <20170825023024.10565-22-igor.mitsyanko.os@quantenna.com>
> - if (tlv_full_len > payload_len) {
> - pr_warn("VIF%u.%u: malformed TLV 0x%.2X; LEN: %u\n",
> - mac->macid, vif->vifid, tlv_type,
> - tlv_value_len);
> + if (tlv_full_len > payload_len)
> return -EINVAL;
> - }
Why drop this sanity check ?
> if (tlv_type == QTN_TLV_ID_IE_SET) {
> - sinfo.assoc_req_ies = tlv->val;
> - sinfo.assoc_req_ies_len = tlv_value_len;
> + const struct qlink_tlv_ie_set *ie_set;
> + unsigned int ie_len;
> +
> + if (payload_len < sizeof(*ie_set))
> + return -EINVAL;
> +
> + ie_set = (const struct qlink_tlv_ie_set *)tlv;
> + ie_len = tlv_value_len -
> + (sizeof(*ie_set) - sizeof(ie_set->hdr));
> +
> + if (ie_set->type == QLINK_IE_SET_ASSOC_REQ && ie_len) {
> + sinfo.assoc_req_ies = ie_set->ie_data;
> + sinfo.assoc_req_ies_len = ie_len;
> + }
> }
Does it make sense to keep QTN_TLV_ID_IE_SET here at all ?
Maybe replace it completely by qlink_tlv_ie_set with
QLINK_IE_SET_ASSOC_REQ type ? Also see the comment below
for the similar snippet in qtnf_event_handle_scan_results.
...
> - if (tlv_full_len > payload_len) {
> - pr_warn("VIF%u.%u: malformed TLV 0x%.2X; LEN: %u\n",
> - vif->mac->macid, vif->vifid, tlv_type,
> - tlv_value_len);
> + if (tlv_full_len > payload_len)
> return -EINVAL;
> - }
ditto
...
> if (tlv_type == QTN_TLV_ID_IE_SET) {
> - ies = tlv->val;
> - ies_len = tlv_value_len;
> + const struct qlink_tlv_ie_set *ie_set;
> + unsigned int ie_len;
> +
> + if (payload_len < sizeof(*ie_set))
> + return -EINVAL;
> +
> + ie_set = (const struct qlink_tlv_ie_set *)tlv;
> + ie_len = tlv_value_len -
> + (sizeof(*ie_set) - sizeof(ie_set->hdr));
> +
> + if (ie_len) {
> + ies = ie_set->ie_data;
> + ies_len = ie_len;
> + }
> }
> }
Two points here. First, it looks like there is a problem here inherited
from the existing implementation. We go through payload, but in fact we
pass to cfg80211_inform_bss only the last QTN_TLV_ID_IE_SET element.
Second, it looks like QTN_TLV_ID_IE_SET here should be treated in
the same way as in qtnf_event_handle_sta_assoc, to avoid confusion.
In other words, either we use only QTN_TLV_ID_IE_SET in both cases,
or switch to specific qlink_tlv_ie_set elements.
Thoughts ? Comments ?
Regards,
Sergey
^ permalink raw reply
* Re: [PATCH 21/27] qtnfmac: extend "IE set" TLV to include frame type info
From: Sergey Matyukevich @ 2017-08-30 12:20 UTC (permalink / raw)
To: igor.mitsyanko.os, linux-wireless, avinashp, johannes
In-Reply-To: <20170830120635.62m2eupefizpgcto@bars>
> Two points here. First, it looks like there is a problem here inherited
> from the existing implementation. We go through payload, but in fact we
> pass to cfg80211_inform_bss only the last QTN_TLV_ID_IE_SET element.
> Second, it looks like QTN_TLV_ID_IE_SET here should be treated in
> the same way as in qtnf_event_handle_sta_assoc, to avoid confusion.
> In other words, either we use only QTN_TLV_ID_IE_SET in both cases,
> or switch to specific qlink_tlv_ie_set elements.
Ignore the second point: it is addressed by the next patch.
Regards,
Sergey
^ permalink raw reply
* Re: [PATCH 23/27] qtnfmac: convert "Append IEs" command to QTN_TLV_ID_IE_SET usage
From: Sergey Matyukevich @ 2017-08-30 12:35 UTC (permalink / raw)
To: igor.mitsyanko.os; +Cc: linux-wireless, avinashp, johannes
In-Reply-To: <20170825023024.10565-24-igor.mitsyanko.os@quantenna.com>
> - if (sizeof(*cmd) + len > QTNF_MAX_CMD_BUF_SIZE) {
> + if (len > QTNF_MAX_CMD_BUF_SIZE) {
> pr_warn("VIF%u.%u: %u frame is too big: %zu\n", vif->mac->macid,
> vif->vifid, frame_type, len);
> return -E2BIG;
It looks like we need the following check here:
sizeof(struct qlink_tlv_ie_set) + len > QTNF_MAX_CMD_BUF_SIZE
^ permalink raw reply
* Re: [PATCH v1 3/6] staging: unisys: Switch to use new generic UUID API
From: Christoph Hellwig @ 2017-08-30 12:38 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Greg Kroah-Hartman, Andy Shevchenko, devel, linux-efi,
linux-watchdog, sparmaintainer, open list:TI WILINK WIRELES...,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
Lukas Wunner, devel, Christoph Hellwig
In-Reply-To: <1501521625.29303.308.camel@linux.intel.com>
On Mon, Jul 31, 2017 at 08:20:25PM +0300, Andy Shevchenko wrote:
> Yep! There are so many conflicts that would be better just to push
> through your tree.
>
> I have just sent a v2 of this patch separately.
Greg, did you pick that patch up?
^ permalink raw reply
* Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API
From: Christoph Hellwig @ 2017-08-30 12:41 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Andy Shevchenko, Mika Westerberg, Andy Shevchenko,
linux-acpi@vger.kernel.org, devel, sparmaintainer, devel,
open list:TI WILINK WIRELES..., linux-watchdog, linux-efi,
Christoph Hellwig, linux-kernel@vger.kernel.org, Lukas Wunner
In-Reply-To: <6349641.0fe8FCM51k@aspire.rjw.lan>
On Wed, Jul 26, 2017 at 02:27:44AM +0200, Rafael J. Wysocki wrote:
> > >> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > >> > Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> > >>
> > >> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > >
> > > OK
> > >
> > > Andy, do you want me to apply this?
> >
> > If you would like to.
> >
> > The patch is now pretty independent since necessary stuff made v4.13-rc1.
>
> OK
This didn't seem to make it into linux-next so far, though.
^ permalink raw reply
* Re: [PATCH v1 1/6] efi: Switch to use new generic UUID API
From: Christoph Hellwig @ 2017-08-30 12:41 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-acpi, devel, sparmaintainer, devel, linux-wireless,
linux-watchdog, linux-efi, Christoph Hellwig, linux-kernel,
Lukas Wunner, Matt Fleming, Ard Biesheuvel
In-Reply-To: <20170719182857.73693-2-andriy.shevchenko@linux.intel.com>
Thanks,
applied to the uuid for-next tree.
^ permalink raw reply
* Re: [PATCH 24/27] qtnfmac: configure and start AP interface with a single command
From: Sergey Matyukevich @ 2017-08-30 13:07 UTC (permalink / raw)
To: igor.mitsyanko.os; +Cc: linux-wireless, avinashp, johannes
In-Reply-To: <20170825023024.10565-25-igor.mitsyanko.os@quantenna.com>
> This separation would not allow to do a proper device configuration as
> first stage needs to use information from IEs that are processed on
> a second stage. Which means first and second stages have to be meged.
> In that case there is no point anymore to keep third stage either, so
> merge all three into a single command.
typo in commit message: 'meged'
> + if (len > (sizeof(struct qlink_cmd) + QTNF_MAX_CMD_BUF_SIZE)) {
> + pr_err("VIF%u.%u: can not fit AP settings: %u\n",
> + vif->mac->macid, vif->vifid, len);
> + return false;
> }
Initial len value is sizeof(struct qlink_cmd_start_ap), qlink_cmd is a part
of qlink_cmd_start_ap. So this check has to be fixed. It looks like the
simplest option is only to check payload: set initial len value to 0
and drop sizeof in comparison.
^ permalink raw reply
* Re: [PATCH v1 3/6] staging: unisys: Switch to use new generic UUID API
From: Andy Shevchenko @ 2017-08-30 13:09 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Greg Kroah-Hartman, Andy Shevchenko, devel, linux-efi,
linux-watchdog, sparmaintainer, open list:TI WILINK WIRELES...,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
Lukas Wunner, devel, Christoph Hellwig
In-Reply-To: <20170830123845.lw4vkjbcvivi5hpi@infradead.org>
On Wed, 2017-08-30 at 14:38 +0200, Christoph Hellwig wrote:
> On Mon, Jul 31, 2017 at 08:20:25PM +0300, Andy Shevchenko wrote:
> > Yep! There are so many conflicts that would be better just to push
> > through your tree.
> >
> > I have just sent a v2 of this patch separately.
>
> Greg, did you pick that patch up?
That patch in his tree.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH v1 3/6] staging: unisys: Switch to use new generic UUID API
From: Greg Kroah-Hartman @ 2017-08-30 13:11 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andy Shevchenko, Andy Shevchenko, devel, linux-efi,
linux-watchdog, sparmaintainer, open list:TI WILINK WIRELES...,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
Lukas Wunner, devel, Christoph Hellwig
In-Reply-To: <20170830123845.lw4vkjbcvivi5hpi@infradead.org>
On Wed, Aug 30, 2017 at 02:38:45PM +0200, Christoph Hellwig wrote:
> On Mon, Jul 31, 2017 at 08:20:25PM +0300, Andy Shevchenko wrote:
> > Yep! There are so many conflicts that would be better just to push
> > through your tree.
> >
> > I have just sent a v2 of this patch separately.
>
> Greg, did you pick that patch up?
Yes, it's already in my tree and in linux-next.
thanks,
greg k-h
^ permalink raw reply
* Re: brcmfmac4356-pci device not seeing 2.4Ghz channel 12 and 13
From: Hans de Goede @ 2017-08-30 13:39 UTC (permalink / raw)
To: Arend van Spriel
Cc: open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
linux-wireless
In-Reply-To: <1b37a554-a69d-53ed-1c66-ab1edceb9af4@broadcom.com>
Hi,
On 06-07-17 21:43, Arend van Spriel wrote:
> On 06-07-17 21:23, Hans de Goede wrote:
>> Hi,
>>
>> On 28-06-17 14:35, Arend Van Spriel wrote:
>>> Op 28 jun. 2017 12:07 schreef "Hans de Goede" <hdegoede@redhat.com
>>> <mailto:hdegoede@redhat.com>>:
>>> >
>>> > Hi,
>>> >
>>> > I noticed today that my GPD Win (x86 clamshell mini laptop)
>>> > which uses a brcmfmac4356-pci wifi does not see an APs which
>>> > is using channel 13.
>>> >
>>> > I've tried updating brcmfmac4356-pci.txt changing "ccode=US"
>>> > to "ccode=EU" and then rebooted, but that does not help.
>>>
>>> Some variables may be stored on the device. However, EU may not be
>>> valid. Could you try NL instead?
>>
>> Yes changing it to NL fixes this. This is still a bit problematic
>> though. Because what are we going to put in the nvram file we want
>> to put in linux-firmware ?
>
> Agree. I am surprised (not pleasantly) that these devices are not
> properly programmed and thus need nvram for the country code.
>
>>> > I believe that the Linux wifi stack is supposed to automatically
>>> > figure out the country settings based on AP provided info ?
>>>
>>> That depends. The device runs its own wifi stack which should have
>>> 802.11d support for what you describe.
>>>
>>> > But that does not seem to be working here ? Any hints on howto
>>> > debug this further would be appreciated.
>>>
>>> You could try doing "country" iovar get somewhere in
>>> brcmf_bus_started() to check country setting in firmware.
>>
>> Let me know if you still want me to do this given that ccode=NL fixes this.
>
> Well. Could you try it with ccode commented out in nvram file.
That does not work, so then I looked at some of my other brcm
nvram files which use:
ccode=XY
ccode=0
ccode=ALL
I tried both 0 and ALL, which both don't work with the brcmfmac4356-pci
controller / firmware.
Then I decided to do a duckduckgo search for this problem and found:
https://wireless.wiki.kernel.org/en/users/Drivers/brcm80211
Which says:
"This generation of chips contain additional regulatory support independent of the driver. The devices use a single worldwide regulatory domain, with channels 12-14 (2.4 GHz band) and channels 52-64 and 100-140 (5 GHz band) restricted to passive operation. Transmission on those channels is suppressed until appropriate other traffic is observed on those channels. Within the driver, we use the ficticious country code “X2” to represent this worldwide regulatory domain."
So I tried:
ccode=X2
And that works :) So case closed.
I also tried another device which has a brcmfmac43430a0 and the stock
nvram from the OS image from the manufacturer uses:
ccode=ALL
And again no joy for accessing an AP on channel 13, switching to:
ccode=X2
Fixed things there too.
Regards,
Hans
^ permalink raw reply
* [PATCH v2] brcmfmac: Log chip id and revision
From: Hans de Goede @ 2017-08-30 13:54 UTC (permalink / raw)
To: Arend van Spriel, Kalle Valo
Cc: Hans de Goede, linux-wireless, brcm80211-dev-list.pdl
For debugging some problems, it is useful to know the chip revision
add a brcmf_info message logging this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Put the brcmf_info in brcmf_fw_map_chip_to_name() so that it works for
e.g. pcie devices too
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index d231042f19d6..091b52979e03 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -601,6 +601,9 @@ int brcmf_fw_map_chip_to_name(u32 chip, u32 chiprev,
if ((nvram_name) && (mapping_table[i].nvram))
strlcat(nvram_name, mapping_table[i].nvram, BRCMF_FW_NAME_LEN);
+ brcmf_info("using %s for chip %#08x(%d) rev %#08x\n",
+ fw_name, chip, chip, chiprev);
+
return 0;
}
--
2.13.4
^ permalink raw reply related
* Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API
From: Rafael J. Wysocki @ 2017-08-30 13:46 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andy Shevchenko, Mika Westerberg, Andy Shevchenko,
linux-acpi@vger.kernel.org, devel, sparmaintainer, devel,
open list:TI WILINK WIRELES..., linux-watchdog, linux-efi,
Christoph Hellwig, linux-kernel@vger.kernel.org, Lukas Wunner
In-Reply-To: <20170830124141.oa32gzbgnafarkrh@infradead.org>
On Wednesday, August 30, 2017 2:41:41 PM CEST Christoph Hellwig wrote:
> On Wed, Jul 26, 2017 at 02:27:44AM +0200, Rafael J. Wysocki wrote:
> > > >> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > > >> > Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > >>
> > > >> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > >
> > > > OK
> > > >
> > > > Andy, do you want me to apply this?
> > >
> > > If you would like to.
> > >
> > > The patch is now pretty independent since necessary stuff made v4.13-rc1.
> >
> > OK
>
> This didn't seem to make it into linux-next so far, though.
I have
3689d3d69072 ACPI: device property: Switch to use new generic UUID API
in my linux-next branch. Isn't it this one?
^ permalink raw reply
* Re: [PATCH v1 6/6] device property: Switch to use new generic UUID API
From: Christoph Hellwig @ 2017-08-30 13:57 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Christoph Hellwig, Andy Shevchenko, Mika Westerberg,
Andy Shevchenko, linux-acpi@vger.kernel.org, devel,
sparmaintainer, devel, open list:TI WILINK WIRELES...,
linux-watchdog, linux-efi, Christoph Hellwig,
linux-kernel@vger.kernel.org, Lukas Wunner
In-Reply-To: <2441703.fLWibNLWr6@aspire.rjw.lan>
On Wed, Aug 30, 2017 at 03:46:34PM +0200, Rafael J. Wysocki wrote:
> 3689d3d69072 ACPI: device property: Switch to use new generic UUID API
>
> in my linux-next branch. Isn't it this one?
Yes, that should be it. Somehow my linux-next tree seems to be
a mess through or my git log skills aren't what they used to be
anymore.
^ permalink raw reply
* Re: [PATCH 06/27] qtnfmac: pass full channel definition to device on start_ap command
From: Sergey Matyukevich @ 2017-08-30 14:02 UTC (permalink / raw)
To: igor.mitsyanko.os; +Cc: linux-wireless, avinashp, johannes
In-Reply-To: <20170825023024.10565-7-igor.mitsyanko.os@quantenna.com>
> + if (s->ssid && s->ssid_len > 0 && s->ssid_len <= IEEE80211_MAX_SSID_LEN)
> + qtnf_cmd_skb_put_tlv_arr(cmd_skb, WLAN_EID_SSID, s->ssid,
> + s->ssid_len);
> +
> + if (cfg80211_chandef_valid(&s->chandef)) {
> + struct qlink_tlv_chandef *chtlv =
> + (struct qlink_tlv_chandef *)skb_put(cmd_skb,
> + sizeof(*chtlv));
> +
> + chtlv->hdr.type = cpu_to_le16(QTN_TLV_ID_CHANDEF);
> + chtlv->hdr.len = sizeof(*chtlv) - sizeof(chtlv->hdr);
It looks like cpu_to_le16 is needed here as well.
> + qlink_chandef_cfg2q(&s->chandef, &chtlv->chan);
> + }
> +
^ permalink raw reply
* [PATCH] rtlwifi: btcoex: 23b 1ant: fix duplicated code for different branches
From: Gustavo A. R. Silva @ 2017-08-30 13:42 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel, Gustavo A. R. Silva
Refactor code in order to avoid identical code for different branches.
This issue was detected with the help of Coccinelle.
Addresses-Coverity-ID: 1226788
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
This issue was reported by Coverity and it was tested by compilation only.
I'm suspicious this may be a copy/paste error. Please, verify.
.../net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
index c044252..960ce80f 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
@@ -2260,14 +2260,8 @@ static void halbtc8723b1ant_run_coexist_mechanism(struct btc_coexist *btcoexist)
if (iot_peer != BTC_IOT_PEER_CISCO &&
iot_peer != BTC_IOT_PEER_BROADCOM) {
- if (bt_link_info->sco_exist)
- halbtc8723b1ant_limited_rx(btcoexist,
- NORMAL_EXEC, false,
- false, 0x5);
- else
- halbtc8723b1ant_limited_rx(btcoexist,
- NORMAL_EXEC, false,
- false, 0x5);
+ halbtc8723b1ant_limited_rx(btcoexist, NORMAL_EXEC,
+ false, false, 0x5);
} else {
if (bt_link_info->sco_exist) {
halbtc8723b1ant_limited_rx(btcoexist,
--
2.5.0
^ permalink raw reply related
* [PATCH] rsi: sdio suspend and resume support
From: Amitkumar Karwar @ 2017-08-30 14:09 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, Amitkumar Karwar, Prameela Rani Garnepudi,
Karun Eagalapati
From: Karun Eagalapati <karun256@gmail.com>
SDIO suspend and resume handlers are implemented and verified
that device works after suspend/resume cycle.
Signed-off-by: Karun Eagalapati <karun256@gmail.com>
Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com>
---
drivers/net/wireless/rsi/rsi_91x_sdio.c | 126 +++++++++++++++++++++++++++++++-
drivers/net/wireless/rsi/rsi_sdio.h | 2 +
2 files changed, 124 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c
index 8d3a483..855b605 100644
--- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
+++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
@@ -1059,16 +1059,134 @@ static void rsi_disconnect(struct sdio_func *pfunction)
}
#ifdef CONFIG_PM
+static int rsi_set_sdio_pm_caps(struct rsi_hw *adapter)
+{
+ struct rsi_91x_sdiodev *dev =
+ (struct rsi_91x_sdiodev *)adapter->rsi_dev;
+ struct sdio_func *func = dev->pfunction;
+ int ret;
+
+ ret = sdio_set_host_pm_flags(func, MMC_PM_KEEP_POWER);
+ if (ret)
+ rsi_dbg(ERR_ZONE, "Set sdio keep pwr flag failed: %d\n", ret);
+
+ return ret;
+}
+
+static int rsi_sdio_disable_interrupts(struct sdio_func *pfunc)
+{
+ struct rsi_hw *adapter = sdio_get_drvdata(pfunc);
+ u8 isr_status = 0, data = 0;
+ int ret;
+
+ rsi_dbg(INFO_ZONE, "Waiting for interrupts to be cleared..");
+ do {
+ rsi_sdio_read_register(adapter, RSI_FN1_INT_REGISTER,
+ &isr_status);
+ rsi_dbg(INFO_ZONE, ".");
+ } while (isr_status);
+ rsi_dbg(INFO_ZONE, "Interrupts cleared\n");
+
+ sdio_claim_host(pfunc);
+ ret = rsi_cmd52readbyte(pfunc->card, RSI_INT_ENABLE_REGISTER, &data);
+ if (ret < 0) {
+ rsi_dbg(ERR_ZONE,
+ "%s: Failed to read int enable register\n",
+ __func__);
+ goto done;
+ }
+
+ data &= RSI_INT_ENABLE_MASK;
+ ret = rsi_cmd52writebyte(pfunc->card, RSI_INT_ENABLE_REGISTER, data);
+ if (ret < 0) {
+ rsi_dbg(ERR_ZONE,
+ "%s: Failed to write to int enable register\n",
+ __func__);
+ goto done;
+ }
+ ret = rsi_cmd52readbyte(pfunc->card, RSI_INT_ENABLE_REGISTER, &data);
+ if (ret < 0) {
+ rsi_dbg(ERR_ZONE,
+ "%s: Failed to read int enable register\n",
+ __func__);
+ goto done;
+ }
+ rsi_dbg(INFO_ZONE, "int enable reg content = %x\n", data);
+
+done:
+ sdio_release_host(pfunc);
+ return ret;
+}
+
+static int rsi_sdio_enable_interrupts(struct sdio_func *pfunc)
+{
+ u8 data;
+ int ret;
+
+ sdio_claim_host(pfunc);
+ ret = rsi_cmd52readbyte(pfunc->card, RSI_INT_ENABLE_REGISTER, &data);
+ if (ret < 0) {
+ rsi_dbg(ERR_ZONE,
+ "%s: Failed to read int enable register\n", __func__);
+ goto done;
+ }
+
+ data |= ~RSI_INT_ENABLE_MASK & 0xff;
+
+ ret = rsi_cmd52writebyte(pfunc->card, RSI_INT_ENABLE_REGISTER, data);
+ if (ret < 0) {
+ rsi_dbg(ERR_ZONE,
+ "%s: Failed to write to int enable register\n",
+ __func__);
+ goto done;
+ }
+
+ ret = rsi_cmd52readbyte(pfunc->card, RSI_INT_ENABLE_REGISTER, &data);
+ if (ret < 0) {
+ rsi_dbg(ERR_ZONE,
+ "%s: Failed to read int enable register\n", __func__);
+ goto done;
+ }
+ rsi_dbg(INFO_ZONE, "int enable reg content = %x\n", data);
+
+done:
+ sdio_release_host(pfunc);
+ return ret;
+}
+
static int rsi_suspend(struct device *dev)
{
- /* Not yet implemented */
- return -ENOSYS;
+ int ret;
+ struct sdio_func *pfunction = dev_to_sdio_func(dev);
+ struct rsi_hw *adapter = sdio_get_drvdata(pfunction);
+ struct rsi_common *common;
+
+ if (!adapter) {
+ rsi_dbg(ERR_ZONE, "Device is not ready\n");
+ return -ENODEV;
+ }
+ common = adapter->priv;
+ rsi_sdio_disable_interrupts(pfunction);
+
+ ret = rsi_set_sdio_pm_caps(adapter);
+ if (ret)
+ rsi_dbg(INFO_ZONE,
+ "Setting power management caps failed\n");
+ common->fsm_state = FSM_CARD_NOT_READY;
+
+ return 0;
}
static int rsi_resume(struct device *dev)
{
- /* Not yet implemented */
- return -ENOSYS;
+ struct sdio_func *pfunction = dev_to_sdio_func(dev);
+ struct rsi_hw *adapter = sdio_get_drvdata(pfunction);
+ struct rsi_common *common = adapter->priv;
+
+ common->fsm_state = FSM_MAC_INIT_DONE;
+ rsi_sdio_enable_interrupts(pfunction);
+
+ return 0;
}
static const struct dev_pm_ops rsi_pm_ops = {
diff --git a/drivers/net/wireless/rsi/rsi_sdio.h b/drivers/net/wireless/rsi/rsi_sdio.h
index 95e4bed..49c549b 100644
--- a/drivers/net/wireless/rsi/rsi_sdio.h
+++ b/drivers/net/wireless/rsi/rsi_sdio.h
@@ -48,6 +48,8 @@ enum sdio_interrupt_type {
#define RSI_DEVICE_BUFFER_STATUS_REGISTER 0xf3
#define RSI_FN1_INT_REGISTER 0xf9
+#define RSI_INT_ENABLE_REGISTER 0x04
+#define RSI_INT_ENABLE_MASK 0xfc
#define RSI_SD_REQUEST_MASTER 0x10000
/* FOR SD CARD ONLY */
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] iwlwifi: pcie: move rx workqueue initialization to iwl_trans_pcie_alloc()
From: David Weinehall @ 2017-08-30 14:57 UTC (permalink / raw)
To: Luca Coelho
Cc: jikos, linux-wireless, luciano.coelho, linux-kernel, linuxwifi,
rui.zhang, edubezval, linux-pm, david.weinehall, johannes.berg,
kvalo, sara.sharon, emmanuel.grumbach
In-Reply-To: <20170822073729.4856-1-luca@coelho.fi>
On Tue, Aug 22, 2017 at 10:37:29AM +0300, Luca Coelho wrote:
> From: Luca Coelho <luciano.coelho@intel.com>
>
> Work queues cannot be allocated when a mutex is held because the mutex
> may be in use and that would make it sleep. Doing so generates the
> following splat with 4.13+:
>
> [ 19.513298] ======================================================
> [ 19.513429] WARNING: possible circular locking dependency detected
> [ 19.513557] 4.13.0-rc5+ #6 Not tainted
> [ 19.513638] ------------------------------------------------------
> [ 19.513767] cpuhp/0/12 is trying to acquire lock:
> [ 19.513867] (&tz->lock){+.+.+.}, at: [<ffffffff924afebb>] thermal_zone_get_temp+0x5b/0xb0
> [ 19.514047]
> [ 19.514047] but task is already holding lock:
> [ 19.514166] (cpuhp_state){+.+.+.}, at: [<ffffffff91cc4baa>] cpuhp_thread_fun+0x3a/0x210
> [ 19.514338]
> [ 19.514338] which lock already depends on the new lock.
>
> This lock dependency already existed with previous kernel versions,
> but it was not detected until commit 49dfe2a67797 ("cpuhotplug: Link
> lock stacks for hotplug callbacks") was introduced.
>
> Reported-by: David Weinehall <david.weinehall@intel.com>
> Reported-by: Jiri Kosina <jikos@kernel.org>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
With this patch I no longer get the lockdep warning,
and the driver seems to work just as well as before.
Thanks!
Tested-by: David Weinehall <david.weinehall@linux.intel.com>
> ---
> In v2:
> - updated the commit message to a new version, with a grammar fix
> and the actual commit that exposed the problem;
>
> drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 2 ++
> drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 10 +---------
> drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 9 +++++++++
> 3 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
> index fa315d84e98e..a1ea9ef97ed9 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
> @@ -787,6 +787,8 @@ int iwl_pci_fw_enter_d0i3(struct iwl_trans *trans);
>
> void iwl_pcie_enable_rx_wake(struct iwl_trans *trans, bool enable);
>
> +void iwl_pcie_rx_allocator_work(struct work_struct *data);
> +
> /* common functions that are used by gen2 transport */
> void iwl_pcie_apm_config(struct iwl_trans *trans);
> int iwl_pcie_prepare_card_hw(struct iwl_trans *trans);
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> index 351c4423125a..942736d3fa75 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> @@ -597,7 +597,7 @@ static void iwl_pcie_rx_allocator_get(struct iwl_trans *trans,
> rxq->free_count += RX_CLAIM_REQ_ALLOC;
> }
>
> -static void iwl_pcie_rx_allocator_work(struct work_struct *data)
> +void iwl_pcie_rx_allocator_work(struct work_struct *data)
> {
> struct iwl_rb_allocator *rba_p =
> container_of(data, struct iwl_rb_allocator, rx_alloc);
> @@ -900,10 +900,6 @@ static int _iwl_pcie_rx_init(struct iwl_trans *trans)
> return err;
> }
> def_rxq = trans_pcie->rxq;
> - if (!rba->alloc_wq)
> - rba->alloc_wq = alloc_workqueue("rb_allocator",
> - WQ_HIGHPRI | WQ_UNBOUND, 1);
> - INIT_WORK(&rba->rx_alloc, iwl_pcie_rx_allocator_work);
>
> spin_lock(&rba->lock);
> atomic_set(&rba->req_pending, 0);
> @@ -1017,10 +1013,6 @@ void iwl_pcie_rx_free(struct iwl_trans *trans)
> }
>
> cancel_work_sync(&rba->rx_alloc);
> - if (rba->alloc_wq) {
> - destroy_workqueue(rba->alloc_wq);
> - rba->alloc_wq = NULL;
> - }
>
> iwl_pcie_free_rbs_pool(trans);
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> index f95eec52508e..3927bbf04f72 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> @@ -1786,6 +1786,11 @@ void iwl_trans_pcie_free(struct iwl_trans *trans)
> iwl_pcie_tx_free(trans);
> iwl_pcie_rx_free(trans);
>
> + if (trans_pcie->rba.alloc_wq) {
> + destroy_workqueue(trans_pcie->rba.alloc_wq);
> + trans_pcie->rba.alloc_wq = NULL;
> + }
> +
> if (trans_pcie->msix_enabled) {
> for (i = 0; i < trans_pcie->alloc_vecs; i++) {
> irq_set_affinity_hint(
> @@ -3169,6 +3174,10 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct pci_dev *pdev,
> trans_pcie->inta_mask = CSR_INI_SET_MASK;
> }
>
> + trans_pcie->rba.alloc_wq = alloc_workqueue("rb_allocator",
> + WQ_HIGHPRI | WQ_UNBOUND, 1);
> + INIT_WORK(&trans_pcie->rba.rx_alloc, iwl_pcie_rx_allocator_work);
> +
> #ifdef CONFIG_IWLWIFI_PCIE_RTPM
> trans->runtime_pm_mode = IWL_PLAT_PM_MODE_D0I3;
> #else
> --
> 2.14.1
>
^ permalink raw reply
* Re: [PATCH 00/27] qtnfmac: allow to configure channel, BW, HT/VHT caps
From: Kalle Valo @ 2017-08-30 16:16 UTC (permalink / raw)
To: igor.mitsyanko.os
Cc: linux-wireless, sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <20170825023024.10565-1-igor.mitsyanko.os@quantenna.com>
igor.mitsyanko.os@quantenna.com writes:
> This patchset has a goal to make operational parameters (channel, BW,
> HT/VHT capabilities) configuration possible for qtnfmac driver.
> Basically the idea is to make driver level as thin as possible, and let
> everything to be handled by userspace/nl80211 and wireless device itself.
This patchset is just too big and pain to review. Preferably no more
than 10-12 patches per set, please. If the patches bigger then the limit
should be even lower.
--
Kalle Valo
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2017-08-30
From: Kalle Valo @ 2017-08-30 16:19 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1504085929.31031.8.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> Here's my fourth and final pull-request intended for v4.14.=C2=A0 It cont=
ains
> just a couple of small fixes and a FW API number bump.=C2=A0=C2=A0More de=
tails in
> the tag description.
>
> I have fixed the subject of one of the patches for the typo you reported
> during review.
>
> I have sent this out before, and kbuildbot reported success.
>
> Please let me know if there are any issues.
>
> Cheers,
> Luca.
>
>
> The following changes since commit d081a16db80ef7a260fb178aa1199e01f74326=
25:
>
> net: bcmgenet: Do not return from void function (2017-08-29 22:39:51 -0=
700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git =
tags/iwlwifi-next-for-kalle-2017-08-30
>
> for you to fetch changes up to d7a5b3e9e42ee95190742fef0d617bbde4f74d80:
>
> iwlwifi: mvm: bump API to 34 for 8000 and up (2017-08-30 12:30:56 +0300)
>
> ----------------------------------------------------------------
> Last set of iwlwifi patches for 4.14
>
> * Fix a queue hang problem due to 11w behavior
> * Fix a warning caused by a too long debug print
> * Bump API number to the latest version we support
>
> ----------------------------------------------------------------
Pulled, thanks.
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH 00/27] qtnfmac: allow to configure channel, BW, HT/VHT caps
From: Kalle Valo @ 2017-08-30 16:22 UTC (permalink / raw)
To: igor.mitsyanko.os
Cc: linux-wireless, sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <87ziahni8p.fsf@purkki.adurom.net>
Kalle Valo <kvalo@codeaurora.org> writes:
> igor.mitsyanko.os@quantenna.com writes:
>
>> This patchset has a goal to make operational parameters (channel, BW,
>> HT/VHT capabilities) configuration possible for qtnfmac driver.
>> Basically the idea is to make driver level as thin as possible, and let
>> everything to be handled by userspace/nl80211 and wireless device itself.
>
> This patchset is just too big and pain to review. Preferably no more
> than 10-12 patches per set, please. If the patches bigger then the limit
> should be even lower.
And I noticed that patch 25 didn't make it to patchwork:
https://patchwork.kernel.org/project/linux-wireless/list/?state=*&q=qtnfmac
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 00/27] qtnfmac: allow to configure channel, BW, HT/VHT caps
From: Kalle Valo @ 2017-08-30 16:28 UTC (permalink / raw)
To: igor.mitsyanko.os
Cc: linux-wireless, sergey.matyukevich.os, avinashp, johannes
In-Reply-To: <87val5nhyq.fsf@purkki.adurom.net>
Kalle Valo <kvalo@codeaurora.org> writes:
> Kalle Valo <kvalo@codeaurora.org> writes:
>
>> igor.mitsyanko.os@quantenna.com writes:
>>
>>> This patchset has a goal to make operational parameters (channel, BW,
>>> HT/VHT capabilities) configuration possible for qtnfmac driver.
>>> Basically the idea is to make driver level as thin as possible, and let
>>> everything to be handled by userspace/nl80211 and wireless device itself.
>>
>> This patchset is just too big and pain to review. Preferably no more
>> than 10-12 patches per set, please. If the patches bigger then the limit
>> should be even lower.
>
> And I noticed that patch 25 didn't make it to patchwork:
>
> https://patchwork.kernel.org/project/linux-wireless/list/?state=*&q=qtnfmac
Actually it did but it was an nl80211 patch:
https://patchwork.kernel.org/patch/9921179/
Never ever hide mac80211 or cfg80211 patches within driver patches like
this. They need to be submitted separately so that everyone sees them.
In some cases it makes sense to submit the driver patches using the new
cfg80211/mac80211 feature at the same, but then do it so that you have
the cfg80211/mac80211 patches and the corresponding driver patches as
last. In that case I assign the whole patchset first to Johannes and
once he has applied the cfg80211/mac80211 patches he assigns the driver
patches to me.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] rtlwifi: btcoex: 23b 1ant: fix duplicated code for different branches
From: Larry Finger @ 2017-08-30 16:37 UTC (permalink / raw)
To: Gustavo A. R. Silva, Pkshih, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20170830134223.GA13596@embeddedgus>
On 08/30/2017 08:42 AM, Gustavo A. R. Silva wrote:
> Refactor code in order to avoid identical code for different branches.
>
> This issue was detected with the help of Coccinelle.
>
> Addresses-Coverity-ID: 1226788
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> This issue was reported by Coverity and it was tested by compilation only.
> I'm suspicious this may be a copy/paste error. Please, verify.
I have referred this change to the engineers at Realtek. For the moment, please
hold this patch.
Thanks for reporting the condition.
Larry
^ permalink raw reply
* Re: [PATCH 5/5] qtnfmac: implement 64-bit dma support
From: Kalle Valo @ 2017-08-30 16:38 UTC (permalink / raw)
To: Sergey Matyukevich; +Cc: linux-wireless, Igor Mitsyanko, Avinash Patil
In-Reply-To: <20170829121623.24761-6-sergey.matyukevich.os@quantenna.com>
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> writes:
> Use 64-bit dma for hosts with CONFIG_ARCH_DMA_ADDR_T_64BIT enabled.
>
> Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
> ---
> .../net/wireless/quantenna/qtnfmac/pearl/pcie.c | 70 ++++++++++++++++++----
> .../wireless/quantenna/qtnfmac/pearl/pcie_ipc.h | 10 ++--
> .../quantenna/qtnfmac/pearl/pcie_regs_pearl.h | 1 +
> 3 files changed, 65 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
> index 2921d8069bf2..502e72b7cdcc 100644
> --- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
> +++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
> @@ -403,10 +403,12 @@ static int alloc_bd_table(struct qtnf_pcie_bus_priv *priv)
> priv->rx_bd_vbase = vaddr;
> priv->rx_bd_pbase = paddr;
>
> - writel(QTN_HOST_LO32(paddr),
> - PCIE_HDP_TX_HOST_Q_BASE_L(priv->pcie_reg_base));
> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> writel(QTN_HOST_HI32(paddr),
> PCIE_HDP_TX_HOST_Q_BASE_H(priv->pcie_reg_base));
> +#endif
Personally I detest ifdefs and try to write code like this using
IS_ENABLED():
if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT))
writel(QTN_HOST_HI32(paddr),
PCIE_HDP_TX_HOST_Q_BASE_H(priv->pcie_reg_base));
But up to you which style you prefer.
--
Kalle Valo
^ permalink raw reply
* Re: [2/2] rsi: update some comments
From: Kalle Valo @ 2017-08-30 16:49 UTC (permalink / raw)
To: Dan Carpenter
Cc: Prameela Rani Garnepudi, Amitkumar Karwar, Karun Eagalapati,
Johannes Berg, Andrew Zaborowski, linux-wireless, kernel-janitors
In-Reply-To: <20170825084037.gxgsieknkb5hxdfs@mwanda>
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> These functions don't return -1 on failure.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> index 25331aa16e8e..e78e87e99804 100644
> --- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> +++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> @@ -754,7 +754,7 @@ static int rsi_mac80211_conf_tx(struct ieee80211_hw *hw,
> * @vif: Pointer to the ieee80211_vif structure.
> * @key: Pointer to the ieee80211_key_conf structure.
> *
> - * Return: status: 0 on success, -1 on failure.
> + * Return: status: 0 on success, negative error codes on failure.
> */
> static int rsi_hal_key_config(struct ieee80211_hw *hw,
> struct ieee80211_vif *vif,
> @@ -1194,7 +1194,7 @@ static void rsi_set_min_rate(struct ieee80211_hw *hw,
> * @vif: Pointer to the ieee80211_vif structure.
> * @sta: Pointer to the ieee80211_sta structure.
> *
> - * Return: 0 on success, -1 on failure.
> + * Return: 0 on success, negative error codes on failure.
> */
> static int rsi_mac80211_sta_add(struct ieee80211_hw *hw,
> struct ieee80211_vif *vif,
> @@ -1306,7 +1306,7 @@ static int rsi_mac80211_sta_add(struct ieee80211_hw *hw,
> * @vif: Pointer to the ieee80211_vif structure.
> * @sta: Pointer to the ieee80211_sta structure.
> *
> - * Return: 0 on success, -1 on failure.
> + * Return: 0 on success, negative error codes on failure.
> */
> static int rsi_mac80211_sta_remove(struct ieee80211_hw *hw,
> struct ieee80211_vif *vif,
> @@ -1426,7 +1426,7 @@ static int rsi_mac80211_set_antenna(struct ieee80211_hw *hw,
> * @tx_ant: Bitmap for tx antenna
> * @rx_ant: Bitmap for rx antenna
> *
> - * Return: 0 on success, -1 on failure.
> + * Return: 0 on success, negative error codes on failure.
> */
> static int rsi_mac80211_get_antenna(struct ieee80211_hw *hw,
> u32 *tx_ant, u32 *rx_ant)
> @@ -1533,7 +1533,7 @@ static struct ieee80211_ops mac80211_ops = {
> * rsi_mac80211_attach() - This function is used to initialize Mac80211 stack.
> * @common: Pointer to the driver private structure.
> *
> - * Return: 0 on success, -1 on failure.
> + * Return: 0 on success, negative error codes on failure.
> */
> int rsi_mac80211_attach(struct rsi_common *common)
> {
2 patches applied to wireless-drivers-next.git, thanks.
fc4386729491 rsi: update some comments
0270639e899e rsi: missing unlocks on error paths
--
https://patchwork.kernel.org/patch/9921425/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] rt2800: fix TX_PIN_CFG setting for non MT7620 chips
From: Kalle Valo @ 2017-08-30 16:50 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Daniel Golle
In-Reply-To: <20170825150414.GA9283@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not
> initialize TX_PIN_CFG setting. This cause breakage at least on some
> RT3573 devices. To fix the problem patch restores previous behaviour
> for non MT7620 chips.
>
> Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1480829
> Reported-and-tested-by: Jussi Eloranta <jussi.eloranta@csun.edu>
> Cc: Daniel Golle <daniel@makrotopia.org>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> Acked-by: Daniel Golle <daniel@makrotopia.org>
Patch applied to wireless-drivers-next.git, thanks.
83ec48919389 rt2800: fix TX_PIN_CFG setting for non MT7620 chips
--
https://patchwork.kernel.org/patch/9922285/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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