* Re: [RFC v3 0/8] ath10k sdio support
From: Erik Stromdahl @ 2017-02-19 13:19 UTC (permalink / raw)
To: Valo, Kalle
Cc: linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org <ath10k@lists.infradead.org>;
In-Reply-To: <877f4ngii5.fsf@kamboji.qca.qualcomm.com>
Hej,
I just noticed that Ryan Hsu submitted two patches containing similar
functionality to what I have in my tree on github. They have not been
integrated in the ath master yet, but they have been added to master-pending.
Below are the commits I am talking about
bc1054a15be3c962c83aa22476a3e9c1266da792 ath10k: improve the firmware download time for QCA9377
db5af2a25bd8c1410ec4456d1d4f4e6ded2649ca ath10k: improve the firmware download time for QCA6174
Since some of my patches overlap with these I think it would be best if
I add these to my tree and rewrite my patches.
If they haven't made it into master before I submit my updated patch series
I will include them in my set.
Is this OK?
If they will be added to master soon there is no issue since I will of course
rebase to the latest ath-YYYYMMDDHHmm before I submit anything.
/Erik
On 2017-02-19 00:57, Valo, Kalle wrote:
> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>
>> I was actually about to email you about this.
>>
>> I have made a few more updates to the sdio code so I think it would be
>> best if I could submit a new series of patches based on this code (v4).
>>
>> Then you can tweak it (v5).
>>
>> It is only minor updates to the HIF layer (added QCA9377 support) and
>> a setup of some pll registers.
>
> Ok, that sounds good. I'll wait for v4.
>
>> btw, should I still mark them as RFC or should it be PATCH this time?
>>
>> If I go for PATCH, should the version be v4 or should I start from v1?
>
> v4 would be fine. Thanks.
>
^ permalink raw reply
* Re: [PATCH] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules
From: Ryan Mounce @ 2017-02-19 12:36 UTC (permalink / raw)
To: Sebastian Gottschall; +Cc: Seth Forshee, wireless-regdb, linux-wireless
In-Reply-To: <b21a95a8-2a84-7bba-24b2-6d2ab3d255c1@dd-wrt.com>
Australian regulations differ from most of Europe, the USA and even
New Zealand (which shares AS/NZS 4268) in that any unlicensed
operation between 5600-5650MHz is prohibited outright, rather than
being allowed after an extended DFS channel availability check.
The situation appears to be similar in Canada, the regdb has
previously been amended to reflect this.
https://git.kernel.org/cgit/linux/kernel/git/sforshee/wireless-regdb.git/co=
mmit/db.txt?id=3Dce7697d3def48f87427b3a3c285b46241af3b79d
On 19 February 2017 at 22:46, Sebastian Gottschall
<s.gottschall@dd-wrt.com> wrote:
> Am 19.02.2017 um 01:01 schrieb Ryan Mounce:
>>
>> Hi Sebastian,
>>
>> There is no explicit channel width restriction in the document,
>> however the only band in which the current regdb rules permit 160MHz
>> operation (5490-5710MHz) would result in an overlap with the
>> restricted weather radar band 5600-5650MHz.
>
> thats the case for all countries, so this couldnt be a argument. dfs shou=
ld
> handle this
>
>>
>> While remaining in compliance with both 802.11 and Australian law,
>> contiguous 160MHz operation in 5GHz is only permitted between
>> 5170-5330MHz which spans two bands with slightly different
>> requirements, hence AUTO-BW.
>>
>> Regards,
>> Ryan Mounce
>>
>> ryan@mounce.com.au
>>
>> On 19 February 2017 at 07:15, Sebastian Gottschall
>> <s.gottschall@dd-wrt.com> wrote:
>>>
>>> maybe i'm blind. but you reduced the channel width from 160 to 80 mhz.
>>> but i
>>> can't find any restriction in the document in a quick review
>>>
>>> Sebastian
>>>
>>>
>>> Am 18.02.2017 um 07:35 schrieb Ryan Mounce:
>>>>
>>>> Sourced from the latest legislation at
>>>> https://www.legislation.gov.au/Details/F2016C0043
>>>>
>>>> The current rules exceed legal limits between 5250-5330MHz, and permit
>>>> illegal operation in 5600-5650MHz (reserved for weather radar).
>>>>
>>>> Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
>>>> ---
>>>> db.txt | 15 ++++++++++-----
>>>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/db.txt b/db.txt
>>>> index 05108e0..b951e0c 100644
>>>> --- a/db.txt
>>>> +++ b/db.txt
>>>> @@ -85,12 +85,17 @@ country AT: DFS-ETSI
>>>> # 60 GHz band channels 1-4, ref: Etsi En 302 567
>>>> (57000 - 66000 @ 2160), (40)
>>>> +# Source:
>>>> +# https://www.legislation.gov.au/Details/F2016C00432
>>>> +# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B
>>>> country AU: DFS-ETSI
>>>> - (2402 - 2482 @ 40), (20)
>>>> - (5170 - 5250 @ 80), (17), AUTO-BW
>>>> - (5250 - 5330 @ 80), (24), DFS, AUTO-BW
>>>> - (5490 - 5710 @ 160), (24), DFS
>>>> - (5735 - 5835 @ 80), (30)
>>>> + (2402 - 2482 @ 40), (36)
>>>> + (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
>>>> + (5250 - 5330 @ 80), (23), NO-OUTDOOR, AUTO-BW, DFS
>>>> + (5490 - 5590 @ 80), (30), DFS
>>>> + (5650 - 5730 @ 80), (30), DFS
>>>> + (5735 - 5835 @ 80), (36)
>>>> + (57000 - 66000 @ 2160), (43), NO-OUTDOOR
>>>> country AW: DFS-ETSI
>>>> (2402 - 2482 @ 40), (20)
>>>
>>>
>>>
>>> --
>>> Mit freundlichen Gr=C3=BCssen / Regards
>>>
>>> Sebastian Gottschall / CTO
>>>
>>> NewMedia-NET GmbH - DD-WRT
>>> Firmensitz: Berliner Ring 101, 64625 Bensheim
>>> Registergericht: Amtsgericht Darmstadt, HRB 25473
>>> Gesch=C3=A4ftsf=C3=BChrer: Peter Steinh=C3=A4user, Christian Scheele
>>> http://www.dd-wrt.com
>>> email: s.gottschall@dd-wrt.com
>>> Tel.: +496251-582650 / Fax: +496251-5826565
>>>
>
>
> --
> Mit freundlichen Gr=C3=BCssen / Regards
>
> Sebastian Gottschall / CTO
>
> NewMedia-NET GmbH - DD-WRT
> Firmensitz: Berliner Ring 101, 64625 Bensheim
> Registergericht: Amtsgericht Darmstadt, HRB 25473
> Gesch=C3=A4ftsf=C3=BChrer: Peter Steinh=C3=A4user, Christian Scheele
> http://www.dd-wrt.com
> email: s.gottschall@dd-wrt.com
> Tel.: +496251-582650 / Fax: +496251-5826565
>
^ permalink raw reply
* Re: [PATCH] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules
From: Sebastian Gottschall @ 2017-02-19 12:16 UTC (permalink / raw)
To: Ryan Mounce, seth.forshee; +Cc: wireless-regdb, linux-wireless
In-Reply-To: <CAN+fvRYkbeV8yXuA+J1HVtZemB+j-07wvHkbouEpgzL-7SE6-Q@mail.gmail.com>
Am 19.02.2017 um 01:01 schrieb Ryan Mounce:
> Hi Sebastian,
>
> There is no explicit channel width restriction in the document,
> however the only band in which the current regdb rules permit 160MHz
> operation (5490-5710MHz) would result in an overlap with the
> restricted weather radar band 5600-5650MHz.
thats the case for all countries, so this couldnt be a argument. dfs
should handle this
>
> While remaining in compliance with both 802.11 and Australian law,
> contiguous 160MHz operation in 5GHz is only permitted between
> 5170-5330MHz which spans two bands with slightly different
> requirements, hence AUTO-BW.
>
> Regards,
> Ryan Mounce
>
> ryan@mounce.com.au
>
> On 19 February 2017 at 07:15, Sebastian Gottschall
> <s.gottschall@dd-wrt.com> wrote:
>> maybe i'm blind. but you reduced the channel width from 160 to 80 mhz. but i
>> can't find any restriction in the document in a quick review
>>
>> Sebastian
>>
>>
>> Am 18.02.2017 um 07:35 schrieb Ryan Mounce:
>>> Sourced from the latest legislation at
>>> https://www.legislation.gov.au/Details/F2016C0043
>>>
>>> The current rules exceed legal limits between 5250-5330MHz, and permit
>>> illegal operation in 5600-5650MHz (reserved for weather radar).
>>>
>>> Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
>>> ---
>>> db.txt | 15 ++++++++++-----
>>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/db.txt b/db.txt
>>> index 05108e0..b951e0c 100644
>>> --- a/db.txt
>>> +++ b/db.txt
>>> @@ -85,12 +85,17 @@ country AT: DFS-ETSI
>>> # 60 GHz band channels 1-4, ref: Etsi En 302 567
>>> (57000 - 66000 @ 2160), (40)
>>> +# Source:
>>> +# https://www.legislation.gov.au/Details/F2016C00432
>>> +# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B
>>> country AU: DFS-ETSI
>>> - (2402 - 2482 @ 40), (20)
>>> - (5170 - 5250 @ 80), (17), AUTO-BW
>>> - (5250 - 5330 @ 80), (24), DFS, AUTO-BW
>>> - (5490 - 5710 @ 160), (24), DFS
>>> - (5735 - 5835 @ 80), (30)
>>> + (2402 - 2482 @ 40), (36)
>>> + (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
>>> + (5250 - 5330 @ 80), (23), NO-OUTDOOR, AUTO-BW, DFS
>>> + (5490 - 5590 @ 80), (30), DFS
>>> + (5650 - 5730 @ 80), (30), DFS
>>> + (5735 - 5835 @ 80), (36)
>>> + (57000 - 66000 @ 2160), (43), NO-OUTDOOR
>>> country AW: DFS-ETSI
>>> (2402 - 2482 @ 40), (20)
>>
>>
>> --
>> Mit freundlichen Grüssen / Regards
>>
>> Sebastian Gottschall / CTO
>>
>> NewMedia-NET GmbH - DD-WRT
>> Firmensitz: Berliner Ring 101, 64625 Bensheim
>> Registergericht: Amtsgericht Darmstadt, HRB 25473
>> Geschäftsführer: Peter Steinhäuser, Christian Scheele
>> http://www.dd-wrt.com
>> email: s.gottschall@dd-wrt.com
>> Tel.: +496251-582650 / Fax: +496251-5826565
>>
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ permalink raw reply
* [PATCH] NFC: st21nfca: Fix potential memory leak
From: Christophe JAILLET @ 2017-02-19 9:58 UTC (permalink / raw)
To: lauro.venancio, aloisio.almeida, sameo, christophe.ricard
Cc: linux-wireless, linux-kernel, kernel-janitors, Christophe JAILLET
If all bits of 'dev_mask' are already set, there is a memory leak because
'info' should be freed before returning.
While fixing it, 'return -ENOMEM' directly if the first kzalloc fails.
This makes the code more readable.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/nfc/st21nfca/core.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/nfc/st21nfca/core.c b/drivers/nfc/st21nfca/core.c
index dacb9166081b..50be3b788f1c 100644
--- a/drivers/nfc/st21nfca/core.c
+++ b/drivers/nfc/st21nfca/core.c
@@ -959,10 +959,8 @@ int st21nfca_hci_probe(void *phy_id, struct nfc_phy_ops *phy_ops,
unsigned long quirks = 0;
info = kzalloc(sizeof(struct st21nfca_hci_info), GFP_KERNEL);
- if (!info) {
- r = -ENOMEM;
- goto err_alloc_hdev;
- }
+ if (!info)
+ return -ENOMEM;
info->phy_ops = phy_ops;
info->phy_id = phy_id;
@@ -978,8 +976,10 @@ int st21nfca_hci_probe(void *phy_id, struct nfc_phy_ops *phy_ops,
* persistent info to discriminate 2 identical chips
*/
dev_num = find_first_zero_bit(dev_mask, ST21NFCA_NUM_DEVICES);
- if (dev_num >= ST21NFCA_NUM_DEVICES)
- return -ENODEV;
+ if (dev_num >= ST21NFCA_NUM_DEVICES) {
+ r = -ENODEV;
+ goto err_alloc_hdev;
+ }
set_bit(dev_num, dev_mask);
--
2.9.3
^ permalink raw reply related
* RE: [RFC 2/5] iwlwifi: fix request_module() use
From: Grumbach, Emmanuel @ 2017-02-19 9:47 UTC (permalink / raw)
To: Luis R. Rodriguez, Berg, Johannes, Coelho, Luciano, tj@kernel.org,
arjan@linux.intel.com, ming.lei@canonical.com, zajec5@gmail.com
Cc: jeyu@redhat.com, rusty@rustcorp.com.au, pmladek@suse.com,
gregkh@linuxfoundation.org, linuxwifi,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20170217020903.6370-3-mcgrof@kernel.org>
>
> The return value of request_module() being 0 does not mean that the driver
> which was requested has loaded. To properly check that the driver was
> loaded each driver can use internal mechanisms to vet the driver is now
> present. The helper try_then_request_module() was added to help with
> this, allowing drivers to specify their own validation as the first argument.
>
> On iwlwifi the use case is a bit more complicated given that the value we
> need to check for is protected with a mutex later used on the
> module_init() of the module we are asking for. If we were to lock and
> request_module() we'd deadlock. iwlwifi needs its own wrapper then so it
> can handle its special locking requirements.
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
I don't see the problem with the current code. We don't assume that everything has been
loaded immediately after request_module returns. We just free the intermediate firmware
structures that won't be using anymore. What happens here is that after request_module
returns, we patiently wait until it is loaded, and when that happens, iwl{d,m}vm's init function
will be called. That one is the one that continues the flow by calling:
ret = iwl_opmode_register("iwlmvm", &iwl_mvm_ops);
(for the iwlmvm case).
Where am I wrong here?
> ---
> drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 34 ++++++++++++++++++++---
> -----
> 1 file changed, 25 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> index e198d6f5fcea..6beb92d19ea7 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> @@ -1231,6 +1231,29 @@ static void _iwl_op_mode_stop(struct iwl_drv
> *drv)
> }
> }
>
> +static void iwlwifi_try_load_op(struct iwlwifi_opmode_table *op,
> + struct iwl_drv *drv)
> +{
> + int ret = 0;
> +
> + ret = request_module("%s", op->name);
> + if (ret)
> + goto out;
> +
> + mutex_lock(&iwlwifi_opmode_table_mtx);
> + if (!op->ops)
> + ret = -ENOENT;
> + mutex_unlock(&iwlwifi_opmode_table_mtx);
> +
> +out:
> +#ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
> + if (ret)
> + IWL_ERR(drv,
> + "failed to load module %s (error %d), is dynamic
> loading enabled?\n",
> + op->name, ret);
> +#endif
> +}
> +
> /**
> * iwl_req_fw_callback - callback when firmware was loaded
> *
> @@ -1471,15 +1494,8 @@ static void iwl_req_fw_callback(const struct
> firmware *ucode_raw, void *context)
> * else from proceeding if the module fails to load
> * or hangs loading.
> */
> - if (load_module) {
> - err = request_module("%s", op->name);
> -#ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
> - if (err)
> - IWL_ERR(drv,
> - "failed to load module %s (error %d), is
> dynamic loading enabled?\n",
> - op->name, err);
> -#endif
> - }
> + if (load_module)
> + iwlwifi_try_load_op(op, drv);
> goto free;
>
> try_again:
> --
> 2.11.0
^ permalink raw reply
* Re: [PATCH] Fix rtl8187 multicast reception
From: Nils Holland @ 2017-02-19 9:41 UTC (permalink / raw)
To: Kalle Valo; +Cc: Larry Finger, linux-wireless
In-Reply-To: <87lgt28vxz.fsf@purkki.adurom.net>
On Sun, Feb 19, 2017 at 09:46:16AM +0200, Kalle Valo wrote:
> Larry Finger <Larry.Finger@lwfinger.net> writes:
>
> > On 02/18/2017 07:35 PM, Nils Holland wrote:
> >> The rtl8187 doesn't seem to receive multicast data, which, among other
> >> thinks, make it fail to receive RAs in IPv6 networks.
> >>
> >> The cause seems to be that the RTL818X_RX_CONF_MULTICAST flag doesn't
> >> have any effect at all. Fix this issue by setting
> >> RTL818X_RX_CONF_MONITOR instead, which puts the card into monitor mode,
> >> and fixes the problem.
> >>
> >> Signed-off-by: Nils Holland <nholland@tisys.org>
> >> ---
> >> The problem and solution have been tested on an rtl8187b (0bda:8197), but
> >> the fix changes behavior on other cards supported by the driver as well
> >> (like non-b 8187's). Due to lack of hardware, I unfortunately cannot say
> >> if the issue exists on these cards in the first place, or if the fix has
> >> any unwanted consequences there.
>
> BTW, this is good info to have in the actual commit log. No need put it
> under "---" line.
Thanks for the hint, I'll do that better the next time! :-)
> > I would prefer a module parameter that would allow this change to be
> > implemented only if the user takes special action. I suspect that you
> > will have no difficulty preparing such a change. If that is not true,
> > I would be happy to help.
>
> I understand why you prefer having a module parameter but the thing is
> that being able to receive multicast frames is really basic
> functionality. We should not hide it under a module parameter.
Well, this is a tough question, I have to admit that I have a somewhat
weird feeling making a change that also applies to other hardware that
I cannot test on, so I don't know about any negative consequences that
might arise there, especially when the change isn't based on some
official information from some documentation, but rather a result of
trial & error. So I can fully understand Larry's concerns and do in
fact think that a module parameter could be a nice solution, so that
by default the behavior if the driver does not change. From an
end-user standpoint, it's probably always worse to see something break
which has always worked before than it is to have something not work
properly right from the start, but being able to easily find some
parameter to fix this. On the other hand, use of this particular USB
wifi card is probably not so common these days so relatively few
people would notice at all. Tough! I guess I'll submit a module
parameter based v2 of the patch later today, just as Larry suggested!
> Isn't there any other option, for example does anyone have hw to test
> this with other hw? (what exactly?) Or maybe we just take the risk and
> take it as is and revert if problems arise?
Of course, if someone has other hw, more testing would be nice! Any
situation where the card is supposed to receive multicast frames
should be suitable as a test case - in my case, just connecting to my
local network and expecting to see the card pick up RAs and acquire an
IPv6 address is the easiest test case. This works nicely on several
other machines with completely different wifi hardware as well as
wired machines, but fails without the fix on the rtl8187b. It would,
for example, be interesting to see if a non-b 8187 behaves the same or
if things work there out of the box. In that case, instead of doing a
module parameter, I could also change the fix so that it only does
something different on the b-variants of the card and doesn't change
behavior at all on non-b.
Greetings
Nils
^ permalink raw reply
* RE: [RFC 1/5] iwlwifi: fix drv cleanup on opmode registration failure
From: Grumbach, Emmanuel @ 2017-02-19 9:16 UTC (permalink / raw)
To: Luis R. Rodriguez, Berg, Johannes, Coelho, Luciano, tj@kernel.org,
arjan@linux.intel.com, ming.lei@canonical.com, zajec5@gmail.com
Cc: jeyu@redhat.com, rusty@rustcorp.com.au, pmladek@suse.com,
gregkh@linuxfoundation.org, linuxwifi,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20170217020903.6370-2-mcgrof@kernel.org>
Hi Luis,
>
> The firmware async callback handles the device's opmode start call, but
> optionally also allows opmode registration to take care of its opmode start. If
> the firmware callback handles it its error path in case of opmode start failure
> has a few pieces of code missing from the opmode registration. The opmode
> registration hanlder has no cleanup at all. Sync both error paths.
>
> This should in theory fix a detangled drv from the drv list should either of the
> opmode modules loaded and handled registration for the drv.
>
> The path of having the opmode registration deal with the drv opmode start is
> actually the more common path. The other path, from the async callback is
> rathe rare (1/8 or so times for me) -- it happens when the the opmode
> driver's init routine completed prior to the driver's async callback opmode
> start call.
I'd claim it should never happen unless you have several devices on the system using the same
opmode, or unless you do:
modprobe iwlwifi #which will load iwl{d,m}vm
rmmod iwl{d,m}vm #and do _not_ remove iwlwifi
modprobe iwlwifi
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> ---
Luca is OOO, but this looks fine to me.
> drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> index be466a074c1d..e198d6f5fcea 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> @@ -1611,8 +1611,13 @@ int iwl_opmode_register(const char *name, const
> struct iwl_op_mode_ops *ops)
> continue;
> op->ops = ops;
> /* TODO: need to handle exceptional case */
> - list_for_each_entry(drv, &op->drv, list)
> + list_for_each_entry(drv, &op->drv, list) {
> drv->op_mode = _iwl_op_mode_start(drv, op);
> + if (!drv->op_mode) {
> + complete(&drv-
> >request_firmware_complete);
> + device_release_driver(drv->trans->dev);
> + }
> + }
>
> mutex_unlock(&iwlwifi_opmode_table_mtx);
> return 0;
> --
> 2.11.0
^ permalink raw reply
* Re: brcmfmac: BCM4343A0 P2P mode problem
From: Stefan Holzmann @ 2017-02-19 8:03 UTC (permalink / raw)
To: linux-wireless
Thank you for your support. Yes, correct SDIO 0xA9A6 is BCM43430 I was confused by the naming of some firmware files.
What firmware version/file shall be used for this chipset/driver combination?
Currently I'am using the firmware file "fw_bcm43438a0_p2p.bin" from here https://github.com/BPI-SINOVOIP/BPI_WiFi_Firmware/tree/master/ap6212.
I have set the driver parameter "use_p2p_group_interface=1" as you recommended, and now I see following error messages at the kernel log when I try to setup a P2P connection.
[ 59.593565] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
[ 62.163452] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[ 62.169542] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[ 62.175839] brcmfmac: brcmf_cfg80211_add_iface: add iface p2p-wlan0-0 type 8 failed: err=-110
^ permalink raw reply
* Re: [PATCH] Fix rtl8187 multicast reception
From: Kalle Valo @ 2017-02-19 7:46 UTC (permalink / raw)
To: Larry Finger; +Cc: Nils Holland, linux-wireless
In-Reply-To: <2eb1dd33-4d71-86b7-c579-412419e2a2e5@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> On 02/18/2017 07:35 PM, Nils Holland wrote:
>> The rtl8187 doesn't seem to receive multicast data, which, among other
>> thinks, make it fail to receive RAs in IPv6 networks.
>>
>> The cause seems to be that the RTL818X_RX_CONF_MULTICAST flag doesn't
>> have any effect at all. Fix this issue by setting
>> RTL818X_RX_CONF_MONITOR instead, which puts the card into monitor mode,
>> and fixes the problem.
>>
>> Signed-off-by: Nils Holland <nholland@tisys.org>
>> ---
>> The problem and solution have been tested on an rtl8187b (0bda:8197), but
>> the fix changes behavior on other cards supported by the driver as well
>> (like non-b 8187's). Due to lack of hardware, I unfortunately cannot say
>> if the issue exists on these cards in the first place, or if the fix has
>> any unwanted consequences there.
BTW, this is good info to have in the actual commit log. No need put it
under "---" line.
>> If people consider it a bad idea to just always put the card into monitor
>> mode (for example, for performance reasons), I could imagine rewriting this
>> patch so that a module parameter controls this behavior instead.
>
> I would hate to make such a change in the behavior of the driver, and
> have it be applied without the user having any say. The fact that
> setting RTL818X_RX_CONF_MULTICAST does not have the desired effect may
> be due to a firmware error; however, there is no chance of making a
> change there as these devices have embedded/fixed fw.
Or it could be also a problem how we configure the firmware.
> I would prefer a module parameter that would allow this change to be
> implemented only if the user takes special action. I suspect that you
> will have no difficulty preparing such a change. If that is not true,
> I would be happy to help.
I understand why you prefer having a module parameter but the thing is
that being able to receive multicast frames is really basic
functionality. We should not hide it under a module parameter.
Isn't there any other option, for example does anyone have hw to test
this with other hw? (what exactly?) Or maybe we just take the risk and
take it as is and revert if problems arise?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] Fix rtl8187 multicast reception
From: Larry Finger @ 2017-02-19 3:26 UTC (permalink / raw)
To: Nils Holland, linux-wireless
In-Reply-To: <20170219013520.GA3190@tisys.org>
On 02/18/2017 07:35 PM, Nils Holland wrote:
> The rtl8187 doesn't seem to receive multicast data, which, among other
> thinks, make it fail to receive RAs in IPv6 networks.
>
> The cause seems to be that the RTL818X_RX_CONF_MULTICAST flag doesn't
> have any effect at all. Fix this issue by setting
> RTL818X_RX_CONF_MONITOR instead, which puts the card into monitor mode,
> and fixes the problem.
>
> Signed-off-by: Nils Holland <nholland@tisys.org>
> ---
> The problem and solution have been tested on an rtl8187b (0bda:8197), but
> the fix changes behavior on other cards supported by the driver as well
> (like non-b 8187's). Due to lack of hardware, I unfortunately cannot say
> if the issue exists on these cards in the first place, or if the fix has
> any unwanted consequences there.
>
> If people consider it a bad idea to just always put the card into monitor
> mode (for example, for performance reasons), I could imagine rewriting this
> patch so that a module parameter controls this behavior instead.
I would hate to make such a change in the behavior of the driver, and have it be
applied without the user having any say. The fact that setting
RTL818X_RX_CONF_MULTICAST does not have the desired effect may be due to a
firmware error; however, there is no chance of making a change there as these
devices have embedded/fixed fw.
I would prefer a module parameter that would allow this change to be implemented
only if the user takes special action. I suspect that you will have no
difficulty preparing such a change. If that is not true, I would be happy to help.
Larry
>
> drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
> index 231f84db9ab0..56a8686cd367 100644
> --- a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
> +++ b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
> @@ -946,8 +946,7 @@ static int rtl8187_start(struct ieee80211_hw *dev)
> (7 << 13 /* RX FIFO threshold NONE */) |
> (7 << 10 /* MAX RX DMA */) |
> RTL818X_RX_CONF_RX_AUTORESETPHY |
> - RTL818X_RX_CONF_ONLYERLPKT |
> - RTL818X_RX_CONF_MULTICAST;
> + RTL818X_RX_CONF_ONLYERLPKT;
> priv->rx_conf = reg;
> rtl818x_iowrite32(priv, &priv->map->RX_CONF, reg);
>
> @@ -1319,12 +1318,11 @@ static void rtl8187_configure_filter(struct ieee80211_hw *dev,
> priv->rx_conf ^= RTL818X_RX_CONF_FCS;
> if (changed_flags & FIF_CONTROL)
> priv->rx_conf ^= RTL818X_RX_CONF_CTRL;
> - if (changed_flags & FIF_OTHER_BSS)
> - priv->rx_conf ^= RTL818X_RX_CONF_MONITOR;
> - if (*total_flags & FIF_ALLMULTI || multicast > 0)
> - priv->rx_conf |= RTL818X_RX_CONF_MULTICAST;
> + if (*total_flags & FIF_OTHER_BSS ||
> + *total_flags & FIF_ALLMULTI || multicast > 0)
> + priv->rx_conf |= RTL818X_RX_CONF_MONITOR;
> else
> - priv->rx_conf &= ~RTL818X_RX_CONF_MULTICAST;
> + priv->rx_conf &= ~RTL818X_RX_CONF_MONITOR;
>
> *total_flags = 0;
>
> @@ -1332,10 +1330,10 @@ static void rtl8187_configure_filter(struct ieee80211_hw *dev,
> *total_flags |= FIF_FCSFAIL;
> if (priv->rx_conf & RTL818X_RX_CONF_CTRL)
> *total_flags |= FIF_CONTROL;
> - if (priv->rx_conf & RTL818X_RX_CONF_MONITOR)
> + if (priv->rx_conf & RTL818X_RX_CONF_MONITOR) {
> *total_flags |= FIF_OTHER_BSS;
> - if (priv->rx_conf & RTL818X_RX_CONF_MULTICAST)
> *total_flags |= FIF_ALLMULTI;
> + }
>
> rtl818x_iowrite32_async(priv, &priv->map->RX_CONF, priv->rx_conf);
> }
>
--
If I was stranded on an island and the only way to get off
the island was to make a pretty UI, I’d die there.
Linus Torvalds
^ permalink raw reply
* [PATCH] Fix rtl8187 multicast reception
From: Nils Holland @ 2017-02-19 1:35 UTC (permalink / raw)
To: linux-wireless
The rtl8187 doesn't seem to receive multicast data, which, among other
thinks, make it fail to receive RAs in IPv6 networks.
The cause seems to be that the RTL818X_RX_CONF_MULTICAST flag doesn't
have any effect at all. Fix this issue by setting
RTL818X_RX_CONF_MONITOR instead, which puts the card into monitor mode,
and fixes the problem.
Signed-off-by: Nils Holland <nholland@tisys.org>
---
The problem and solution have been tested on an rtl8187b (0bda:8197), but
the fix changes behavior on other cards supported by the driver as well
(like non-b 8187's). Due to lack of hardware, I unfortunately cannot say
if the issue exists on these cards in the first place, or if the fix has
any unwanted consequences there.
If people consider it a bad idea to just always put the card into monitor
mode (for example, for performance reasons), I could imagine rewriting this
patch so that a module parameter controls this behavior instead.
drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
index 231f84db9ab0..56a8686cd367 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
@@ -946,8 +946,7 @@ static int rtl8187_start(struct ieee80211_hw *dev)
(7 << 13 /* RX FIFO threshold NONE */) |
(7 << 10 /* MAX RX DMA */) |
RTL818X_RX_CONF_RX_AUTORESETPHY |
- RTL818X_RX_CONF_ONLYERLPKT |
- RTL818X_RX_CONF_MULTICAST;
+ RTL818X_RX_CONF_ONLYERLPKT;
priv->rx_conf = reg;
rtl818x_iowrite32(priv, &priv->map->RX_CONF, reg);
@@ -1319,12 +1318,11 @@ static void rtl8187_configure_filter(struct ieee80211_hw *dev,
priv->rx_conf ^= RTL818X_RX_CONF_FCS;
if (changed_flags & FIF_CONTROL)
priv->rx_conf ^= RTL818X_RX_CONF_CTRL;
- if (changed_flags & FIF_OTHER_BSS)
- priv->rx_conf ^= RTL818X_RX_CONF_MONITOR;
- if (*total_flags & FIF_ALLMULTI || multicast > 0)
- priv->rx_conf |= RTL818X_RX_CONF_MULTICAST;
+ if (*total_flags & FIF_OTHER_BSS ||
+ *total_flags & FIF_ALLMULTI || multicast > 0)
+ priv->rx_conf |= RTL818X_RX_CONF_MONITOR;
else
- priv->rx_conf &= ~RTL818X_RX_CONF_MULTICAST;
+ priv->rx_conf &= ~RTL818X_RX_CONF_MONITOR;
*total_flags = 0;
@@ -1332,10 +1330,10 @@ static void rtl8187_configure_filter(struct ieee80211_hw *dev,
*total_flags |= FIF_FCSFAIL;
if (priv->rx_conf & RTL818X_RX_CONF_CTRL)
*total_flags |= FIF_CONTROL;
- if (priv->rx_conf & RTL818X_RX_CONF_MONITOR)
+ if (priv->rx_conf & RTL818X_RX_CONF_MONITOR) {
*total_flags |= FIF_OTHER_BSS;
- if (priv->rx_conf & RTL818X_RX_CONF_MULTICAST)
*total_flags |= FIF_ALLMULTI;
+ }
rtl818x_iowrite32_async(priv, &priv->map->RX_CONF, priv->rx_conf);
}
--
2.11.1
^ permalink raw reply related
* Re: [PATCH] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules
From: Ryan Mounce @ 2017-02-19 0:01 UTC (permalink / raw)
To: Sebastian Gottschall, seth.forshee; +Cc: wireless-regdb, linux-wireless
In-Reply-To: <9d768854-e41d-fdb1-967d-7fdd7d692226@dd-wrt.com>
Hi Sebastian,
There is no explicit channel width restriction in the document,
however the only band in which the current regdb rules permit 160MHz
operation (5490-5710MHz) would result in an overlap with the
restricted weather radar band 5600-5650MHz.
While remaining in compliance with both 802.11 and Australian law,
contiguous 160MHz operation in 5GHz is only permitted between
5170-5330MHz which spans two bands with slightly different
requirements, hence AUTO-BW.
Regards,
Ryan Mounce
ryan@mounce.com.au
On 19 February 2017 at 07:15, Sebastian Gottschall
<s.gottschall@dd-wrt.com> wrote:
> maybe i'm blind. but you reduced the channel width from 160 to 80 mhz. bu=
t i
> can't find any restriction in the document in a quick review
>
> Sebastian
>
>
> Am 18.02.2017 um 07:35 schrieb Ryan Mounce:
>>
>> Sourced from the latest legislation at
>> https://www.legislation.gov.au/Details/F2016C0043
>>
>> The current rules exceed legal limits between 5250-5330MHz, and permit
>> illegal operation in 5600-5650MHz (reserved for weather radar).
>>
>> Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
>> ---
>> db.txt | 15 ++++++++++-----
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/db.txt b/db.txt
>> index 05108e0..b951e0c 100644
>> --- a/db.txt
>> +++ b/db.txt
>> @@ -85,12 +85,17 @@ country AT: DFS-ETSI
>> # 60 GHz band channels 1-4, ref: Etsi En 302 567
>> (57000 - 66000 @ 2160), (40)
>> +# Source:
>> +# https://www.legislation.gov.au/Details/F2016C00432
>> +# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B
>> country AU: DFS-ETSI
>> - (2402 - 2482 @ 40), (20)
>> - (5170 - 5250 @ 80), (17), AUTO-BW
>> - (5250 - 5330 @ 80), (24), DFS, AUTO-BW
>> - (5490 - 5710 @ 160), (24), DFS
>> - (5735 - 5835 @ 80), (30)
>> + (2402 - 2482 @ 40), (36)
>> + (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
>> + (5250 - 5330 @ 80), (23), NO-OUTDOOR, AUTO-BW, DFS
>> + (5490 - 5590 @ 80), (30), DFS
>> + (5650 - 5730 @ 80), (30), DFS
>> + (5735 - 5835 @ 80), (36)
>> + (57000 - 66000 @ 2160), (43), NO-OUTDOOR
>> country AW: DFS-ETSI
>> (2402 - 2482 @ 40), (20)
>
>
>
> --
> Mit freundlichen Gr=C3=BCssen / Regards
>
> Sebastian Gottschall / CTO
>
> NewMedia-NET GmbH - DD-WRT
> Firmensitz: Berliner Ring 101, 64625 Bensheim
> Registergericht: Amtsgericht Darmstadt, HRB 25473
> Gesch=C3=A4ftsf=C3=BChrer: Peter Steinh=C3=A4user, Christian Scheele
> http://www.dd-wrt.com
> email: s.gottschall@dd-wrt.com
> Tel.: +496251-582650 / Fax: +496251-5826565
>
^ permalink raw reply
* Re: [RFC v3 0/8] ath10k sdio support
From: Valo, Kalle @ 2017-02-18 23:57 UTC (permalink / raw)
To: Erik Stromdahl; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <1c87e0d1-1f14-08bb-2a69-650788fba8dc@gmail.com>
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> I was actually about to email you about this.
>
> I have made a few more updates to the sdio code so I think it would be
> best if I could submit a new series of patches based on this code (v4).
>
> Then you can tweak it (v5).
>
> It is only minor updates to the HIF layer (added QCA9377 support) and
> a setup of some pll registers.
Ok, that sounds good. I'll wait for v4.
> btw, should I still mark them as RFC or should it be PATCH this time?
>
> If I go for PATCH, should the version be v4 or should I start from v1?
v4 would be fine. Thanks.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [RFC v3 0/8] ath10k sdio support
From: Erik Stromdahl @ 2017-02-18 22:05 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <87fujbhb29.fsf@kamboji.qca.qualcomm.com>
Hej Kalle,
I was actually about to email you about this.
I have made a few more updates to the sdio code so I think it would be
best if I could submit a new series of patches based on this code (v4).
Then you can tweak it (v5).
It is only minor updates to the HIF layer (added QCA9377 support) and
a setup of some pll registers.
I will get back to you shortly.
btw, should I still mark them as RFC or should it be PATCH this time?
If I go for PATCH, should the version be v4 or should I start from v1?
/Erik
On 2017-02-18 14:40, Valo, Kalle wrote:
> Hej,
>
> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>
>> This is the third version of the sdio RFC patch series.
>> The actual sdio code (patch 6) has been subject to a massive overhaul,
>> mainly as a result of Kalle's review comments.
>> It no longer has any strong resemblance of the original ath6kl code from
>> which it was originally based upon.
>>
>> Previous pathes 6 to 10 have been merged into one single patch.
>>
>> The previous series had a rework of the "HTC fake service" connect
>> (ep 0 connect) that introduced a race between the actual endpoint
>> connect and the HTC ready message. This issue has been addressed,
>> and the current patches (3 and 4) has been rewritten accordingly.
>>
>> * overview of patches *
>>
>> Patches 1 to 4 are more or less identical to the previous RFC, with an
>> exception for patch 3 that changes the "HTC fake service" connect
>> (mentioned above).
>>
>> Patch 5 is a squashed version of previous patches 6 to 10.
>>
>> Patch 6 is the actual sdio patch
>>
>> Patches 7 to 8 are new and adds special sdio versions of BMI get
>> target info and HTC ready.
>>
>> The new version was built and tested against:
>> tag: ath-201701121109
>>
>> Erik Stromdahl (8):
>> ath10k: htc: made static function public
>> ath10k: htc: rx trailer lookahead support
>> ath10k: htc: move htc ctrl ep connect to htc_init
>> ath10k: htc: refactorization
>> ath10k: various sdio related definitions
>> ath10k: sdio support
>> ath10k: sdio get target info
>> ath10k: htc: ready_ext msg support
>
> Sorry for not getting back to you earlier, haven't found time to look
> this in detail during the last few weeks.
>
> This is looking quite good now. I have some nitpicks (build warnings,
> maybe reorder some patches etc) still but I think it's faster if I fix
> those and send v4 as a proper patch (no RFC anymore), naturally
> attributing you as the author. Is that ok for you?
>
^ permalink raw reply
* Re: [PATCH] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules
From: Sebastian Gottschall @ 2017-02-18 20:45 UTC (permalink / raw)
To: Ryan Mounce, seth.forshee; +Cc: wireless-regdb, linux-wireless
In-Reply-To: <20170218063515.16071-1-ryan@mounce.com.au>
maybe i'm blind. but you reduced the channel width from 160 to 80 mhz.
but i can't find any restriction in the document in a quick review
Sebastian
Am 18.02.2017 um 07:35 schrieb Ryan Mounce:
> Sourced from the latest legislation at
> https://www.legislation.gov.au/Details/F2016C0043
>
> The current rules exceed legal limits between 5250-5330MHz, and permit
> illegal operation in 5600-5650MHz (reserved for weather radar).
>
> Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
> ---
> db.txt | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/db.txt b/db.txt
> index 05108e0..b951e0c 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -85,12 +85,17 @@ country AT: DFS-ETSI
> # 60 GHz band channels 1-4, ref: Etsi En 302 567
> (57000 - 66000 @ 2160), (40)
>
> +# Source:
> +# https://www.legislation.gov.au/Details/F2016C00432
> +# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B
> country AU: DFS-ETSI
> - (2402 - 2482 @ 40), (20)
> - (5170 - 5250 @ 80), (17), AUTO-BW
> - (5250 - 5330 @ 80), (24), DFS, AUTO-BW
> - (5490 - 5710 @ 160), (24), DFS
> - (5735 - 5835 @ 80), (30)
> + (2402 - 2482 @ 40), (36)
> + (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
> + (5250 - 5330 @ 80), (23), NO-OUTDOOR, AUTO-BW, DFS
> + (5490 - 5590 @ 80), (30), DFS
> + (5650 - 5730 @ 80), (30), DFS
> + (5735 - 5835 @ 80), (36)
> + (57000 - 66000 @ 2160), (43), NO-OUTDOOR
>
> country AW: DFS-ETSI
> (2402 - 2482 @ 40), (20)
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ permalink raw reply
* Re: brcmfmac: BCM4343A0 P2P mode problem
From: Arend Van Spriel @ 2017-02-18 19:25 UTC (permalink / raw)
To: Stefan Holzmann; +Cc: linux-wireless, hostap@lists.infradead.org
In-Reply-To: <trinity-8050cb18-f2b8-4b78-a32c-96b49de20725-1487367187777@3capp-gmx-bs71>
On 17-2-2017 22:33, Stefan Holzmann wrote:
> Hello,
>
> I have problems to get WiFi P2P on a Nanopi NEO Air board up and running. The board uses a AP6212 WiFi module with the BCM4343A0 SDIO chipset (ID: 0xa9a6).
Hi Stefan
FYI, SDIO ID: A9A6 is BCM43430.
> Connecting to an AP as normal WiFi client is working without problems.
>
> I can also discover other WiFi P2P nodes using wpa_cli p2p_peers, but when I try to connect using wpa_cli p2p_connect the connection attempt fails with the following log.
>
> Are there any known problems with this kernel/wpa_supplicant combination for this chipset? Why the interface type can't be changed to P2P_CLIENT? I also tried to use the "p2pon" driver option but when I try to start wpa_supplicant on the P2P interface I get an kernel crash.
You may need to start wpa_supplicant with '-puse_p2p_group_interface=1'.
The use of p2pon parameter is not recommended on recent kernel and 2.x
wpa_supplicant. It requires specific wpa_supplicant command line.
Regards,
Arend
> Kernel Log:
>
> [ 222.972232] brcmfmac: brcmf_cfg80211_escan_handler: scan not ready, bsscfgidx=1
> [ 222.979577] brcmfmac: brcmf_fweh_event_worker: event handler failed (69)
>
> [ 237.677557] brcmfmac: brcmf_cfg80211_change_iface Enter, bsscfgidx=0, type=8
> [ 237.677569] brcmfmac: brcmf_cfg80211_change_iface Exit
> [ 237.677641] brcmfmac: brcmf_netdev_open Enter, bsscfgidx=0
> [ 237.677648] brcmfmac: brcmf_sdio_bus_txctl Enter
> [ 237.677664] brcmfmac: brcmf_sdio_dpc Enter
> [ 237.677674] brcmfmac: brcmf_sdio_tx_ctrlframe Enter
> [ 237.677716] brcmfmac: brcmf_sdio_bus_rxctl Enter
> [ 237.678232] brcmfmac: brcmf_sdio_isr Enter
> [ 237.678244] brcmfmac: brcmf_sdio_dpc Enter
> [ 237.678288] brcmfmac: brcmf_sdio_readframes Enter
> [ 237.678315] brcmfmac: brcmf_sdio_read_control Enter
> [ 237.678359] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame, got 27 expected 27
> [ 237.678365] brcmfmac: brcmf_fil_cmd_data Failed: BCME_UNSUPPORTED (-23)
> [ 237.678370] brcmfmac: brcmf_fil_iovar_data_get ifidx=0, name=toe_ol, len=4
> [ 237.678372] brcmutil: data
> [ 237.678380] 00000000: 84 85 13 c0
>
>
> wpa_supplicant Log:
> nl80211: Set mode ifindex 2 iftype 8 (P2P_CLIENT)
> nl80211: Failed to set interface 2 to mode 8: -22 (Invalid argument)
> nl80211: Try mode change after setting interface down
> nl80211: Set mode ifindex 2 iftype 8 (P2P_CLIENT)
> nl80211: Failed to set interface 2 to mode 8: -22 (Invalid argument)
> nl80211: Interface mode change to 8 from 2 failed
>
>
> Kernel: 4.10.0-rc5
> wpa_supplicant: v2.6
> WiFI Firmware version = wl0: Jun 6 2014 14:50:39 version 7.10.226.49 (r) FWID 01-8962686a
>
>
> Best Regards,
> Stefan Holzmann
>
^ permalink raw reply
* Re: [RFC v3 0/8] ath10k sdio support
From: Valo, Kalle @ 2017-02-18 13:40 UTC (permalink / raw)
To: Erik Stromdahl; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <1484342771-6160-1-git-send-email-erik.stromdahl@gmail.com>
Hej,
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> This is the third version of the sdio RFC patch series.
> The actual sdio code (patch 6) has been subject to a massive overhaul,
> mainly as a result of Kalle's review comments.
> It no longer has any strong resemblance of the original ath6kl code from
> which it was originally based upon.
>
> Previous pathes 6 to 10 have been merged into one single patch.
>
> The previous series had a rework of the "HTC fake service" connect
> (ep 0 connect) that introduced a race between the actual endpoint
> connect and the HTC ready message. This issue has been addressed,
> and the current patches (3 and 4) has been rewritten accordingly.
>
> * overview of patches *
>
> Patches 1 to 4 are more or less identical to the previous RFC, with an
> exception for patch 3 that changes the "HTC fake service" connect
> (mentioned above).
>
> Patch 5 is a squashed version of previous patches 6 to 10.
>
> Patch 6 is the actual sdio patch
>
> Patches 7 to 8 are new and adds special sdio versions of BMI get
> target info and HTC ready.
>
> The new version was built and tested against:
> tag: ath-201701121109
>
> Erik Stromdahl (8):
> ath10k: htc: made static function public
> ath10k: htc: rx trailer lookahead support
> ath10k: htc: move htc ctrl ep connect to htc_init
> ath10k: htc: refactorization
> ath10k: various sdio related definitions
> ath10k: sdio support
> ath10k: sdio get target info
> ath10k: htc: ready_ext msg support
Sorry for not getting back to you earlier, haven't found time to look
this in detail during the last few weeks.
This is looking quite good now. I have some nitpicks (build warnings,
maybe reorder some patches etc) still but I think it's faster if I fix
those and send v4 as a proper patch (no RFC anymore), naturally
attributing you as the author. Is that ok for you?
--=20
Kalle Valo=
^ permalink raw reply
* [PATCH] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules
From: Ryan Mounce @ 2017-02-18 6:35 UTC (permalink / raw)
To: seth.forshee; +Cc: wireless-regdb, linux-wireless
Sourced from the latest legislation at
https://www.legislation.gov.au/Details/F2016C0043
The current rules exceed legal limits between 5250-5330MHz, and permit
illegal operation in 5600-5650MHz (reserved for weather radar).
Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
---
db.txt | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/db.txt b/db.txt
index 05108e0..b951e0c 100644
--- a/db.txt
+++ b/db.txt
@@ -85,12 +85,17 @@ country AT: DFS-ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
+# Source:
+# https://www.legislation.gov.au/Details/F2016C00432
+# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B
country AU: DFS-ETSI
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (17), AUTO-BW
- (5250 - 5330 @ 80), (24), DFS, AUTO-BW
- (5490 - 5710 @ 160), (24), DFS
- (5735 - 5835 @ 80), (30)
+ (2402 - 2482 @ 40), (36)
+ (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
+ (5250 - 5330 @ 80), (23), NO-OUTDOOR, AUTO-BW, DFS
+ (5490 - 5590 @ 80), (30), DFS
+ (5650 - 5730 @ 80), (30), DFS
+ (5735 - 5835 @ 80), (36)
+ (57000 - 66000 @ 2160), (43), NO-OUTDOOR
country AW: DFS-ETSI
(2402 - 2482 @ 40), (20)
--
2.11.0
^ permalink raw reply related
* brcmfmac: BCM4343A0 P2P mode problem
From: Stefan Holzmann @ 2017-02-17 21:33 UTC (permalink / raw)
To: linux-wireless
Hello,
I have problems to get WiFi P2P on a Nanopi NEO Air board up and running. The board uses a AP6212 WiFi module with the BCM4343A0 SDIO chipset (ID: 0xa9a6). Connecting to an AP as normal WiFi client is working without problems.
I can also discover other WiFi P2P nodes using wpa_cli p2p_peers, but when I try to connect using wpa_cli p2p_connect the connection attempt fails with the following log.
Are there any known problems with this kernel/wpa_supplicant combination for this chipset? Why the interface type can't be changed to P2P_CLIENT? I also tried to use the "p2pon" driver option but when I try to start wpa_supplicant on the P2P interface I get an kernel crash.
Kernel Log:
[ 222.972232] brcmfmac: brcmf_cfg80211_escan_handler: scan not ready, bsscfgidx=1
[ 222.979577] brcmfmac: brcmf_fweh_event_worker: event handler failed (69)
[ 237.677557] brcmfmac: brcmf_cfg80211_change_iface Enter, bsscfgidx=0, type=8
[ 237.677569] brcmfmac: brcmf_cfg80211_change_iface Exit
[ 237.677641] brcmfmac: brcmf_netdev_open Enter, bsscfgidx=0
[ 237.677648] brcmfmac: brcmf_sdio_bus_txctl Enter
[ 237.677664] brcmfmac: brcmf_sdio_dpc Enter
[ 237.677674] brcmfmac: brcmf_sdio_tx_ctrlframe Enter
[ 237.677716] brcmfmac: brcmf_sdio_bus_rxctl Enter
[ 237.678232] brcmfmac: brcmf_sdio_isr Enter
[ 237.678244] brcmfmac: brcmf_sdio_dpc Enter
[ 237.678288] brcmfmac: brcmf_sdio_readframes Enter
[ 237.678315] brcmfmac: brcmf_sdio_read_control Enter
[ 237.678359] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame, got 27 expected 27
[ 237.678365] brcmfmac: brcmf_fil_cmd_data Failed: BCME_UNSUPPORTED (-23)
[ 237.678370] brcmfmac: brcmf_fil_iovar_data_get ifidx=0, name=toe_ol, len=4
[ 237.678372] brcmutil: data
[ 237.678380] 00000000: 84 85 13 c0
wpa_supplicant Log:
nl80211: Set mode ifindex 2 iftype 8 (P2P_CLIENT)
nl80211: Failed to set interface 2 to mode 8: -22 (Invalid argument)
nl80211: Try mode change after setting interface down
nl80211: Set mode ifindex 2 iftype 8 (P2P_CLIENT)
nl80211: Failed to set interface 2 to mode 8: -22 (Invalid argument)
nl80211: Interface mode change to 8 from 2 failed
Kernel: 4.10.0-rc5
wpa_supplicant: v2.6
WiFI Firmware version = wl0: Jun 6 2014 14:50:39 version 7.10.226.49 (r) FWID 01-8962686a
Best Regards,
Stefan Holzmann
^ permalink raw reply
* Re: Power Save for Multi-VIF
From: Gucea Doru @ 2017-02-17 20:57 UTC (permalink / raw)
To: linux-wireless, ath9k_htc_fw; +Cc: Andra Paraschiv, Costin Raiciu, Dragos N
In-Reply-To: <CANfLQrbhbn9UavS1sDDhp9wZyoNQN5MdGzXhKywLJApJ8MTwWQ@mail.gmail.com>
On Tue, Feb 14, 2017 at 9:41 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
> Hello, everyone
>
> I try to design a Power Save Algorithm in the case of a mobile client
> that has multiple virtual interfaces [1] and is connected to multiple
> Access Points simultaneously. My implementation is for the Atheros
> AR9271 WiFi chip.
>
> The biggest challenge in implementing this algorithm is waking up the
> WiFi chip for RX traffic. E.g.: the WiFi chip is in the sleep state
> and it has to wake up in order to receive beacons from all the APs
> that the client is connected to.
>
> Reading the AR9271 datasheet [2] I noticed that the chip is equipped
> with hardware timers for waking up the hardware. The registers for
> programming these hardware timers are MAC_PCU_SLP1 and MAC_PCU_SLP2.
> After the registers have been programmed, the RTC_FORCE_WAKE bit has
> to be cleared in order to allow the card to enter sleep mode (at least
> this is how is done in the existing implementation for the single VIF
> scenario).
>
> I used the logic above for programming the hardware to wake up for
> beacons from multiple APs. I used a power device for measuring the
> energy consumption and it seems that the WiFi card wakes up
> periodically to receive beacons from multiple APs. The problem is that
> after a time, out of nowhere, the WiFi card refuses to enter sleep
> mode and stays just in the awake state, although the logic for
> programming the hardware timers does not change.
>
> Could someone give more details about the FORCE_WAKE signal and what
> is the relation between this signal and the MAC and RTC layers? I
> believe that the problem comes from here. The AR9271 datasheet just
> references this signal (page 106) but it offers no details about it.
Is there any Atheros developer that could help me with a clarification
about the FORCE_WAKE signal?
Thanks,
Doru
>
> [1] https://github.com/doru91/linux-stable/wiki/Two-Interfaces-Power-Save
> [2] https://wikidevi.com/wiki/Atheros_AR9271
> [3] http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/hw.c?v=4.9#L2068
>
> Regards,
> Doru
^ permalink raw reply
* [RFC PATCH 2/2 v2] ath9k_htc: Adjust beacon timers for power save
From: Doru @ 2017-02-17 20:54 UTC (permalink / raw)
To: linux-wireless, andra.paraschiv7, costin.raiciu, dragos.niculescu
Cc: Doru Gucea
From: Doru Gucea <gucea.doru@gmail.com>
Each time we receive a beacon we need to adjust the hardware
timers for next DTIM and next TBTT.
Before this commit, the Power Save behaviour was incorrect.
The scenario was:
- STA receives a beacon from AP with TIM unset;
- mac80211 layers puts the chip to sleep;
- chip is woken up by mac80211's software timer reponsible for
beacon miss after 7 * beacon_interval period.
Normally the chip should sleep at most DTIM period. This commit
configures hardware timers for waking up the chip correctly.
More details on the wiki:
https://github.com/doru91/linux-stable/wiki/Single-Interface-Power-Save
Changelog
v1:
* moved beacon configuration call in the ath9k_htc driver
Signed-off-by: Doru Gucea <gucea.doru@gmail.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index a553c91..5403399 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1518,6 +1518,10 @@ static void ath9k_htc_bss_info_changed(struct ieee80211_hw *hw,
mutex_lock(&priv->mutex);
ath9k_htc_ps_wakeup(priv);
+ /* adjust beacon timers */
+ if (changed && BSS_CHANGED_BEACON_INFO)
+ ath9k_htc_beacon_config(priv, vif);
+
if (changed & BSS_CHANGED_ASSOC) {
ath_dbg(common, CONFIG, "BSS Changed ASSOC %d\n",
bss_conf->assoc);
--
1.9.1
^ permalink raw reply related
* [RFC-PATCH 1/2 v2] mac80211: Update the driver with beacon info constantly
From: Doru @ 2017-02-17 20:53 UTC (permalink / raw)
To: linux-wireless, andra.paraschiv7, costin.raiciu, dragos.niculescu
Cc: Doru Gucea
From: Doru Gucea <gucea.doru@gmail.com>
Once the mac80211 layer receives a beacon, it should send a notification
to the driver. This will allow finer timining control in case of drivers
that need a correct estimation for the arrival time of a beacon.
Changelog
v1:
* fixed typo
Signed-off-by: Doru Gucea <gucea.doru@gmail.com>
---
net/mac80211/mlme.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 2398693..f5ebe27 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3548,6 +3548,12 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
sdata->vif.bss_conf.sync_dtim_count = 0;
}
+ /* trigger hardware timers adjustment
+ * this needs to be done before beacon filtering
+ */
+ changed |= BSS_CHANGED_BEACON_INFO;
+ ieee80211_bss_info_change_notify(sdata, changed);
+
if (ncrc == ifmgd->beacon_crc && ifmgd->beacon_crc_valid)
return;
ifmgd->beacon_crc = ncrc;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] rtlwifi: rtl8723bs: Add firmware for new driver
From: Kyle McMartin @ 2017-02-17 17:43 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, netdev, linux-firmware
In-Reply-To: <20170119210427.3542-1-Larry.Finger@lwfinger.net>
On Thu, Jan 19, 2017 at 03:04:27PM -0600, Larry Finger wrote:
> This driver is being added for Fedora users, and will then be added
> to the mainline kernel.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> c: Hans de Goede <hdegoede@redhat.com>
Applied.
^ permalink raw reply
* Re: pull-request: iwlwifi firmwares update 2017-02-03
From: Kyle McMartin @ 2017-02-17 17:58 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi, Grumbach, Emmanuel, linux-firmware
In-Reply-To: <1486111291.26003.86.camel@coelho.fi>
On Fri, Feb 03, 2017 at 10:41:31AM +0200, Luca Coelho wrote:
> Hi Kyle,
>
> We have updated some of our old firmware releases and also added a new
> release, version 27, for the newer devices. More details in the tag
> description.
>
> Please pull or let me know if there are any issues.
>
Thanks Luca, pulled.
regards, Kyle
> Cheers,
> Luca.
>
>
>
> The following changes since commit 6d3bc8886517d171068fd1263176b8b5c51df204:
>
> Fix permissions on ti-connectivity firmware from 05e9fe59 (2017-01-13 10:14:07 -0500)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2017-02-03
>
> for you to fetch changes up to b689306274099710f9f85eaab584604ca11ee54a:
>
> iwlwifi: add -27 firmware for 3168, 7265D, 8000C and 8265 (2017-02-03 10:20:54 +0200)
>
> ----------------------------------------------------------------
> * update -17 firmware binaries for iwlwifi devices 3260, 7260 and 7265
> * update -22 firmware binaries for iwlwifi devices 7265D, 8000C and 8265
> * add -27 firmware binaries for iwlwifi devices 3168, 7265D, 8000C and 8265
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2017-02-17
From: David Miller @ 2017-02-17 18:01 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87wpcql0cm.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Thu, 16 Feb 2017 15:41:13 +0200
> few -next patches I'm still hoping to get to 4.11 to keep my backlog
> short, nothing major here. Please let me know if there are any problems.
Pulled, thanks Kalle.
^ 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