* Re: BCM4356 + Ubuntu 16.10
From: Arend Van Spriel @ 2016-11-21 9:34 UTC (permalink / raw)
To: Familie Stepniak
Cc: mailto:brcm80211-dev-list.pdl@broadcom.com, linux-wireless
In-Reply-To: <AM3PR06MB1043FFF175E7DB0D4DB510D9A3B20@AM3PR06MB1043.eurprd06.prod.outlook.com>
+ linux-wireless
On 20-11-2016 14:26, Familie Stepniak wrote:
> Hi,
>
> I try run Ubuntu 16.10 on the Trekstor W2 Tablet but Wi-Fi donts work..
> that find WLAN-Network, I give to Passwort and Nothing.. the chip ist
> BCM4356B.. please Help me to install the true Driver on the Linux-Ubuntu..
Not sure what "true Driver" means, but let me see if I can help. First
see if I understand your issue. So you were able to select to WLAN
network and got a pop-up to provide the password. After that you are not
getting a connection. Is this right?
So is this a first attempt to run Ubuntu on it or have you been able to
run older version.
Can you do the following:
- open a terminal.
- run following commands (assuming wlan0):
$ iw dev
$ iw list
$ lspci
$ sudo nmcli nm wifi off
$ sudo rfkill unblock wifi
$ sudo ifconfig wlan0 up
$ sudo iw wlan0 scan
$ dmesg
- send me output of all these commands.
Regards,
Arend
^ permalink raw reply
* Re: [ath9k-devel] [RFC v2 2/2] ath9k: Reset chip on potential deaf state
From: Ferry Huberts @ 2016-11-21 9:15 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: ath9k-devel, linux-wireless, ath9k-devel, Simon Wunderlich
In-Reply-To: <2358985.PI5q6nxgha@bentobox>
On 21/11/16 10:10, Sven Eckelmann wrote:
> On Montag, 21. November 2016 10:07:43 CET Ferry Huberts wrote:
> [...]
>>> v2:
>>> - reduce amount of possible goto-raptor attacks by one (thanks Kalle Valo)
>>>
>>> This problem was discovered in mesh setups. It was noticed that some nodes
>>
>>
>> What kind of setup?
>> Using 802.11s?
>
> Unencrypted IBSS.
>
ok, thanks. that is different then.
I _can_ tell you that using the high priority queue (EF class traffic)
seems to somehow 'unwedge' the chip during/after rekeying. Still have to
verify this again, but that is what I saw last week.
^ permalink raw reply
* Re: [ath9k-devel] [RFC v2 2/2] ath9k: Reset chip on potential deaf state
From: Sven Eckelmann @ 2016-11-21 9:10 UTC (permalink / raw)
To: Ferry Huberts; +Cc: ath9k-devel, linux-wireless, ath9k-devel, Simon Wunderlich
In-Reply-To: <d23407cb-a1c0-860a-3436-5e72402a080b@hupie.com>
[-- Attachment #1: Type: text/plain, Size: 324 bytes --]
On Montag, 21. November 2016 10:07:43 CET Ferry Huberts wrote:
[...]
> > v2:
> > - reduce amount of possible goto-raptor attacks by one (thanks Kalle Valo)
> >
> > This problem was discovered in mesh setups. It was noticed that some nodes
>
>
> What kind of setup?
> Using 802.11s?
Unencrypted IBSS.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [ath9k-devel] [RFC v2 2/2] ath9k: Reset chip on potential deaf state
From: Ferry Huberts @ 2016-11-21 9:07 UTC (permalink / raw)
To: Sven Eckelmann, ath9k-devel; +Cc: linux-wireless, ath9k-devel, Simon Wunderlich
In-Reply-To: <20161117083614.19188-2-sven.eckelmann@open-mesh.com>
On 17/11/16 09:36, Sven Eckelmann wrote:
> From: Simon Wunderlich <simon.wunderlich@open-mesh.com>
>
> The chip is switching seemingly random into a state which can be described
> as "deaf". No or nearly no interrupts are generated anymore for incoming
> packets. Existing links either break down after a while and new links will
> not be established.
>
> The driver doesn't know if there is no other device available or if it
> ended up in an "deaf" state. Resetting the chip proactively avoids
> permanent problems in case the chip really was in its "deaf" state but
> maybe causes unnecessary resets in case it wasn't "deaf".
>
> Signed-off-by: Simon Wunderlich <simon.wunderlich@open-mesh.com>
> [sven.eckelmann@open-mesh.com: port to recent ath9k, add commit message]
> Signed-off-by: Sven Eckelmann <sven.eckelmann@open-mesh.com>
> ---
> v2:
> - reduce amount of possible goto-raptor attacks by one (thanks Kalle Valo)
>
> This problem was discovered in mesh setups. It was noticed that some nodes
What kind of setup?
Using 802.11s?
I ask this because I have almost completed a patch for authsae that
checks rekey.
The problems there might show as the behaviour described here.
> were not able to see their neighbors (mostly after running for a while) -
> even when those neighbors received data from them via IBSS. A simple `iw
> dev wlan0 scan` fixed the problem for them. But the problem seems to
> reappear after while(tm) in a large enough(tm) mesh.
>
> This patch is a little bit obscure because it requires CONFIG_ATH9K_DEBUGFS
> to actually work. But there still seems to be potential interest in
> Freifunk communities or Freifunk meta-projects (e.g. freifunk-gluon). It is
> currently not known if it helps them but publishing this to allow them to
> test and play around with it will not hurt :)
> ---
> drivers/net/wireless/ath/ath9k/ath9k.h | 3 +++
> drivers/net/wireless/ath/ath9k/debug.c | 1 +
> drivers/net/wireless/ath/ath9k/debug.h | 1 +
> drivers/net/wireless/ath/ath9k/link.c | 48 +++++++++++++++++++++++++++++++++-
> 4 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
> index 9c6fee7..3987ad5 100644
> --- a/drivers/net/wireless/ath/ath9k/ath9k.h
> +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
> @@ -996,6 +996,9 @@ struct ath_softc {
> short nbcnvifs;
> unsigned long ps_usecount;
>
> + unsigned long last_check_time;
> + u32 last_check_interrupts;
> +
> struct ath_rx rx;
> struct ath_tx tx;
> struct ath_beacon beacon;
> diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
> index 608b370..6d5c253 100644
> --- a/drivers/net/wireless/ath/ath9k/debug.c
> +++ b/drivers/net/wireless/ath/ath9k/debug.c
> @@ -768,6 +768,7 @@ static int read_file_reset(struct seq_file *file, void *data)
> [RESET_TX_DMA_ERROR] = "Tx DMA stop error",
> [RESET_RX_DMA_ERROR] = "Rx DMA stop error",
> [RESET_TYPE_DEADBEEF] = "deadbeef hang",
> + [RESET_TYPE_DEAF] = "deaf hang",
> };
> int i;
>
> diff --git a/drivers/net/wireless/ath/ath9k/debug.h b/drivers/net/wireless/ath/ath9k/debug.h
> index 0d77abbf6..6f186bd 100644
> --- a/drivers/net/wireless/ath/ath9k/debug.h
> +++ b/drivers/net/wireless/ath/ath9k/debug.h
> @@ -53,6 +53,7 @@ enum ath_reset_type {
> RESET_TX_DMA_ERROR,
> RESET_RX_DMA_ERROR,
> RESET_TYPE_DEADBEEF,
> + RESET_TYPE_DEAF,
> __RESET_TYPE_MAX
> };
>
> diff --git a/drivers/net/wireless/ath/ath9k/link.c b/drivers/net/wireless/ath/ath9k/link.c
> index 04195d5..ae99c02 100644
> --- a/drivers/net/wireless/ath/ath9k/link.c
> +++ b/drivers/net/wireless/ath/ath9k/link.c
> @@ -158,13 +158,59 @@ static bool ath_hw_hang_deadbeef(struct ath_softc *sc)
> return true;
> }
>
> +static bool ath_hw_hang_deaf(struct ath_softc *sc)
> +{
> +#ifndef CONFIG_ATH9K_DEBUGFS
> + return false;
> +#else
> + struct ath_common *common = ath9k_hw_common(sc->sc_ah);
> + u32 interrupts, interrupt_per_s;
> + unsigned int interval;
> +
> + /* get historic data */
> + interval = jiffies_to_msecs(jiffies - sc->last_check_time);
> + if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_EDMA)
> + interrupts = sc->debug.stats.istats.rxlp;
> + else
> + interrupts = sc->debug.stats.istats.rxok;
> +
> + interrupts -= sc->last_check_interrupts;
> +
> + /* save current data */
> + sc->last_check_time = jiffies;
> + if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_EDMA)
> + sc->last_check_interrupts = sc->debug.stats.istats.rxlp;
> + else
> + sc->last_check_interrupts = sc->debug.stats.istats.rxok;
> +
> + /* sanity check, should be 30 seconds */
> + if (interval > 40000 || interval < 20000)
> + return false;
> +
> + /* should be at least one interrupt per second */
> + interrupt_per_s = interrupts / (interval / 1000);
> + if (interrupt_per_s >= 1)
> + return false;
> +
> + ath_dbg(common, RESET,
> + "RX deaf hang is detected. Schedule chip reset\n");
> + ath9k_queue_reset(sc, RESET_TYPE_DEAF);
> +
> + return true;
> +#endif
> +}
> +
> void ath_hw_hang_work(struct work_struct *work)
> {
> struct ath_softc *sc = container_of(work, struct ath_softc,
> hw_hang_work.work);
>
> - ath_hw_hang_deadbeef(sc);
> + if (ath_hw_hang_deadbeef(sc))
> + goto requeue_worker;
> +
> + ath_hw_hang_deaf(sc);
>
> +requeue_worker:
> ieee80211_queue_delayed_work(sc->hw, &sc->hw_hang_work,
> msecs_to_jiffies(ATH_HANG_WORK_INTERVAL));
> }
>
--
Ferry Huberts
^ permalink raw reply
* form factor subsystem (Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support)
From: Johannes Berg @ 2016-11-21 8:50 UTC (permalink / raw)
To: Wei-Ning Huang, Linux-Wireless, Luca Coelho, haim.dreyfuss
Cc: Sameer Nanda, Todd Broch, linux-kernel
In-Reply-To: <1462430663-9448-1-git-send-email-wnhuang@chromium.org>
Hi,
I'm revisiting this since we're asked to do the same for iwlwifi.
On Thu, 2016-05-05 at 14:44 +0800, Wei-Ning Huang wrote:
> Recent new hardware has the ability to switch between tablet mode and
> clamshell mode. To optimize WiFi performance, we want to be able to
> use different power table between modes. This patch adds a new
> netlink message type and cfg80211_ops function to allow userspace to
> trigger a power mode switch for a given wireless interface.
I've thought about this a bit more, and also heard this in different
contexts now, and I'm actually not convinced that the wifi subsystem
exposing this *in any way* is the right thing to do.
Why don't we add a minimal "form factor" subsystem to the kernel?
Something that allows
1) sensor/BIOS/... drivers to call a function to switch form factor
2) consumers to register and get callbacks when switching happens
If the sensor driver is in the kernel (some kind of driver probably has
to be anyway), or form factor switch ends up being a BIOS notification,
then this gets rid of a lot of complexity - no more need to bump this
through userspace etc.
If, for some reason, the sensor driver really has to be in userspace,
then some kind of API *to this subsystem* can be implemented to set the
form factor mode from userspace, and all the other stuff can be left as
is.
This would also allow other clients to know about this information,
let's say, for the sake of an argument that doesn't seem *too* far-
fetched, that the compass driver needs to adjust the direction if you
switch modes.
It seems to me that this would be more robust, which can only be a good
thing if we start using it for things that might be regulatory
relevant.
Additionally, the subsystem could allow userspace to also get an event
if it wants to know about this, e.g. to switch to a more touch-friendly
UI on switching to tablet mode, or something.
Thoughts?
johannes
^ permalink raw reply
* RE: Problems getting mwifiex with sd8887 to work
From: Amitkumar Karwar @ 2016-11-21 7:07 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-wireless@vger.kernel.org, Nishant Sarmukadam, Kalle Valo
In-Reply-To: <20161113141348.GA32086@katana>
Hi Wolfram,
> From: Wolfram Sang [mailto:wsa@the-dreams.de]
> Sent: Sunday, November 13, 2016 7:44 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Nishant Sarmukadam; Kalle Valo
> Subject: Re: Problems getting mwifiex with sd8887 to work
>
> > 0x242 command failure is expected for sd8887, as It's not supported.
>
> Is the same true for 0x10f?
>
> mwifiex_sdio mmc2:0001:1: CMD_RESP: cmd 0x10f error, result=0x2
>
> Otherwise I can connect to the network and run performance tests now.
Error code 2 from firmware is unsupported command. You can ignore this and earlier
error seen for 0x242 command. They aren't harmful.
Regards,
Amitkumar
^ permalink raw reply
* Re: [PATCH 4.9.0-rc5] AR9300 calibration problems with antenna selected
From: miaoqing @ 2016-11-21 5:48 UTC (permalink / raw)
To: Krzysztof Hałasa, ath9k-devel, Kalle Valo, linux-wireless,
ath9k-devel, netdev, linux-kernel
In-Reply-To: <61055e757c5645dfb69da3fc555cbcf5@aptaiexm02f.ap.qualcomm.com>
I would prefer that you didn't submit this.
>
> I recently tried to select a single antenna on AR9300 and it works for
> 30 seconds only. The subsequent calibration makes the RX signal level
> to drop from the usual -30/-40 dBm to -70/-80 dBm, and the
> transmission practically stops.
>
> With the attached patch it works, though selecting the antenna doesn't
> seem to have any visible effect, at least with "iw wlanX station dump"
> (perhaps it works for TX).
>
> I'm using ad-hoc mode:
>
> rmmod ath9k
> modprobe ath9k
> iw dev wlan0 set type ibss
> iw phy phyX set antenna 2
2 is a bad mask. We use bitmap, the valid masks are 1, 3, 7.
--
Miaoqing
^ permalink raw reply
* Re: ath10k stuck in mesh mode
From: Michal Kazior @ 2016-11-20 11:09 UTC (permalink / raw)
To: Bob Copeland; +Cc: Matteo Grandi, LinuxWireless Mailing List
In-Reply-To: <20161120010740.GB3581@localhost>
On 20 November 2016 at 02:07, Bob Copeland <me@bobcopeland.com> wrote:
> On Fri, Nov 18, 2016 at 10:43:06PM +0100, Matteo Grandi wrote:
>> So the question is: who decide if use MIMO and higher MCS hopefully on
>> 80MHz channel or not? Is the firmware? Is there a way to force the
>> interface to use 80MHz and/or MIMO? (iw provide the possibility to
>> choose between [HT20/HT40-/HT40+]).
>
> You can specify the channel width like so:
>
> iw dev wlan0 set freq 5745 80 5775
> iw dev wlan0 mesh join mesh-vht
With recent enough `iw` you can check the operational (max) bandwidth
of the interface with:
iw dev wlan0 info
I don't know how mesh nodes negotiate their capabilities to each other
though so I don't know how reliable this is.
Actual modulation is picked by rate control in firmware. You can try
to force a fixed rate with[1]:
iw dev wlan0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:9
It doesn't allow setting fixed bandwidth though so you'll need to
check rx bitrate on the receiving end to verify.
[1]: https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug?s[]=3Ds=
et&s[]=3Dbitrates#manual_bitrates_configuration
Micha=C5=82
^ permalink raw reply
* open-ath9k-htc-firmware as DFSG debian package
From: Oleksij Rempel @ 2016-11-20 10:35 UTC (permalink / raw)
To: linux-wireless, ath9k-devel, ath9k-devel, ath9k_htc_fw
[-- Attachment #1.1: Type: text/plain, Size: 413 bytes --]
Hallo all,
finally we managed to provide debian package for main repository:
https://ftp-master.debian.org/new/open-ath9k-htc-firmware_1.4.0-81-gf206e56+dfsg-1.html
- It is made according Debian Free Software Guideline
- providing debug and source packages
- can be build just in the repository
Have fun by using it :)
Thank to all who helped to make this happening :D
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
^ permalink raw reply
* Re: [PATCH 0/7] rtl8xxxu: Pending patches
From: Barry Day @ 2016-11-20 2:42 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-wireless, kvalo, Larry.Finger
In-Reply-To: <wrfj37inauwp.fsf@redhat.com>
On Sat, Nov 19, 2016 at 06:53:42PM -0500, Jes Sorensen wrote:
> Barry Day <briselec@gmail.com> writes:
> > On Fri, Nov 18, 2016 at 09:00:10PM -0500, Jes Sorensen wrote:
> >> Barry Day <briselec@gmail.com> writes:
> >> > On Fri, Nov 18, 2016 at 04:44:21PM -0500, Jes.Sorensen@redhat.com wrote:
> >> >> From: Jes Sorensen <Jes.Sorensen@redhat.com>
> >> >>
> >> >> Kalle,
> >> >>
> >> >> Please find attached a number of patches for the rtl8xxxu
> >> >> driver.
> >> >>
> >> >> The issues reported with wpa_supplicant on 8723bu still needs further
> >> >> investigation.
> >> >>
> >> >
> >> > The patch I posted that you want tested more will also fix the
> >> > wpa_supplicant issue. Currently I'm looking at why the tx rate is not
> >> > what it should be. I feel fixing that first will be beneficial for
> >> > fixing any other issues.
> >>
> >> Interesting, I was thinking that might be the case. I do want to dig
> >> into this further to understand it better. If we use your solution I
> >> will want to make sure we cover both gen1 and gen2 parts.
> >>
> >> > The recent merge has made my local branch of rtl8xxxu-devel 14
> >> > commits ahead.
> >> > Do I need to do a reset and submit a new patch for the DWA-131 dongle?
> >>
> >> In general you need to use 'git pull --rebase' on my tree. I rebase it
> >> to stay in sync with Kalle's tree.
> >>
> >> The DWA-131 is the 8192eu? Sorry a bit behind and my mind is losing
> >> bits. If it's the patch you posted earlier I can dig it out and play
> >> with it - I am still catching up though, so please be patient.
> >
> > yes it's an 8192eu.
>
> Gotcha - how do you do your testing to reproduce the problem btw? Most
> of my testing is using the 8723au as a primary device and the next
> device as a follow-on, so I may not see as long a run with the device
> active as you see.
>
Testing is simple. Connect to an AP in the usual manner..disconnect..reconnect.
The 8192eu will fail to reconnect and John Heenan reported the 8723bu also
fails to reconnect. Even though he was directly stopping and restarting
wpa_supplicant, it's the same thing to the driver -
connect..disconnect..reconnect.
> > Would you accept a patch that adds a struct device pointer to rtl8xxxu_priv
> > and used as the device pointer in the logging functions? Then all the messages
> > will start with the driver name making them easier to find.
>
> How do you mean? Right now I have a struct usb_device pointer and
> dereference that for ->dev to use with dev_info() messages etc. Do you
> want to see more than that?
>
> Cheers,
> Jes
With using a usb_device pointer, each message starts with the usb bus address.
Plug it into a different port and that address could change. By using a pointer
to the device associated with the wiphy each message will begin with the driver
name. Just makes it easier for the average user to report what's in the log
because he can just grep for "rtl8xxxu".
Barry
^ permalink raw reply
* Re: ath10k stuck in mesh mode
From: Bob Copeland @ 2016-11-20 1:07 UTC (permalink / raw)
To: Matteo Grandi; +Cc: LinuxWireless Mailing List
In-Reply-To: <CAHdg3xaCnAp8rgMs3mVYvV6TFadNjwBtCo+rpHgH_-L8JUo-dw@mail.gmail.com>
On Fri, Nov 18, 2016 at 10:43:06PM +0100, Matteo Grandi wrote:
> So the question is: who decide if use MIMO and higher MCS hopefully on
> 80MHz channel or not? Is the firmware? Is there a way to force the
> interface to use 80MHz and/or MIMO? (iw provide the possibility to
> choose between [HT20/HT40-/HT40+]).
You can specify the channel width like so:
iw dev wlan0 set freq 5745 80 5775
iw dev wlan0 mesh join mesh-vht
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [PATCH 0/7] rtl8xxxu: Pending patches
From: Jes Sorensen @ 2016-11-19 23:53 UTC (permalink / raw)
To: Barry Day; +Cc: linux-wireless, kvalo, Larry.Finger
In-Reply-To: <20161119023830.GA7324@testbox>
Barry Day <briselec@gmail.com> writes:
> On Fri, Nov 18, 2016 at 09:00:10PM -0500, Jes Sorensen wrote:
>> Barry Day <briselec@gmail.com> writes:
>> > On Fri, Nov 18, 2016 at 04:44:21PM -0500, Jes.Sorensen@redhat.com wrote:
>> >> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>> >>
>> >> Kalle,
>> >>
>> >> Please find attached a number of patches for the rtl8xxxu
>> >> driver.
>> >>
>> >> The issues reported with wpa_supplicant on 8723bu still needs further
>> >> investigation.
>> >>
>> >
>> > The patch I posted that you want tested more will also fix the
>> > wpa_supplicant issue. Currently I'm looking at why the tx rate is not
>> > what it should be. I feel fixing that first will be beneficial for
>> > fixing any other issues.
>>
>> Interesting, I was thinking that might be the case. I do want to dig
>> into this further to understand it better. If we use your solution I
>> will want to make sure we cover both gen1 and gen2 parts.
>>
>> > The recent merge has made my local branch of rtl8xxxu-devel 14
>> > commits ahead.
>> > Do I need to do a reset and submit a new patch for the DWA-131 dongle?
>>
>> In general you need to use 'git pull --rebase' on my tree. I rebase it
>> to stay in sync with Kalle's tree.
>>
>> The DWA-131 is the 8192eu? Sorry a bit behind and my mind is losing
>> bits. If it's the patch you posted earlier I can dig it out and play
>> with it - I am still catching up though, so please be patient.
>
> yes it's an 8192eu.
Gotcha - how do you do your testing to reproduce the problem btw? Most
of my testing is using the 8723au as a primary device and the next
device as a follow-on, so I may not see as long a run with the device
active as you see.
> Would you accept a patch that adds a struct device pointer to rtl8xxxu_priv
> and used as the device pointer in the logging functions? Then all the messages
> will start with the driver name making them easier to find.
How do you mean? Right now I have a struct usb_device pointer and
dereference that for ->dev to use with dev_info() messages etc. Do you
want to see more than that?
Cheers,
Jes
^ permalink raw reply
* Re: rtlwifi: rtl8723be: Fix bug in ant_sel code from commit c18d8f509571
From: Kalle Valo @ 2016-11-19 7:24 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, linux-wireless, Ping-Ke Shih, Larry Finger, Stable
In-Reply-To: <20161117180533.16136-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> From: Ping-Ke Shih <pkshih@realtek.com>
>
> In commit c18d8f509571 ("rtlwifi: rtl8723be: Add antenna select module
> parameter"), wifi was fixed for those laptops that have only a single
> antenna but have an incorrectly coded EEPROM. This error causes the
> driver to select the wrong antenna. In that commit, one necessary change
> that affects Bluetooth operation was missed.
>
> Fixes: c18d8f509571 ("rtlwifi: rtl8723be: Add antenna select module parameter")
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org>
Requested by Larry
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9434985/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v4, 01/11] mwifiex: check tx_hw_pending before downloading sleep confirm
From: Kalle Valo @ 2016-11-19 7:19 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, dmitry.torokhov, Shengzhen Li, Amitkumar Karwar
In-Reply-To: <1479477634-27841-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Shengzhen Li <szli@marvell.com>
>
> We may get SLEEP event from firmware even if TXDone interrupt
> for last Tx packet is still pending. In this case, we may
> end up accessing PCIe memory for handling TXDone after power
> save handshake is completed. This causes kernel crash with
> external abort.
>
> This patch will only allow downloading sleep confirm
> when no tx done interrupt is pending in the hardware.
>
> Signed-off-by: Cathy Luo <cluo@marvell.com>
> Signed-off-by: Shengzhen Li <szli@marvell.com>
> Tested-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
11 patches applied to wireless-drivers-next.git, thanks.
eb2428fb1a21 mwifiex: check tx_hw_pending before downloading sleep confirm
6712076883ca mwifiex: complete blocked power save handshake in main process
4a79aa17d53e mwifiex: resolve races between async FW init (failure) and device removal
a1beec4b2c6f mwifiex: remove redundant pdev check in suspend/resume handlers
7ccdf72f9128 mwifiex: don't pretend to resume while remove()'ing
b42dbb27e326 mwifiex: resolve suspend() race with async FW init failure
bcf28a2f2846 mwifiex: reset card->adapter during device unregister
58b7033551cd mwifiex: usb: handle HS failures
6caf34cb3a92 mwifiex: sdio: don't check for NULL sdio_func
e98fb11ffa0a mwifiex: stop checking for NULL drvata/intfdata
97489c284d9f mwifiex: pcie: stop checking for NULL adapter->card
--
https://patchwork.kernel.org/patch/9436513/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v4,1/3] mwifiex: Allow mwifiex early access to device structure
From: Kalle Valo @ 2016-11-19 7:13 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, dmitry.torokhov, Amitkumar Karwar
In-Reply-To: <1479216964-3328-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Rajat Jain <rajatja@google.com>
>
> Today all the interface drivers (usb/pcie/sdio) assign the
> adapter->dev in the register_dev() callback, although they
> have this piece of info well before hand.
>
> This patch makes the device structure available for mwifiex
> right at the beginning, so that it can be used for early
> initialization if needed.
>
> This is needed for subsequent patches in this patchset that
> intend to unify and consolidate some of the code that would
> otherwise have to be duplicated among the interface drivers
> (sdio, pcie, usb).
>
> Signed-off-by: Rajat Jain <rajatja@google.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
3 patches applied to wireless-drivers-next.git, thanks.
2e02b5814217 mwifiex: Allow mwifiex early access to device structure
5e28e5fbdcf0 mwifiex: Introduce mwifiex_probe_of() to parse common properties
853402a00823 mwifiex: Enable WoWLAN for both sdio and pcie
--
https://patchwork.kernel.org/patch/9429835/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v8] mwifiex: parse device tree node for PCIe
From: Kalle Valo @ 2016-11-19 7:11 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, dmitry.torokhov, devicetree, Xinming Hu,
Amitkumar Karwar
In-Reply-To: <1479472624-22340-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> This patch derives device tree node from pcie bus layer framework.
> Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> marvell-8xxx.txt) to accommodate PCIe changes.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Rajat Jain <rajatja@google.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> Acked-by: Rob Herring <robh@kernel.org>
Patch applied to wireless-drivers-next.git, thanks.
6b4480d109b0 mwifiex: parse device tree node for PCIe
--
https://patchwork.kernel.org/patch/9436393/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v8] mwifiex: parse device tree node for PCIe
From: Kalle Valo @ 2016-11-19 6:56 UTC (permalink / raw)
To: Rajat Jain
Cc: Amitkumar Karwar, linux-wireless, Cathy Luo, Nishant Sarmukadam,
Brian Norris, Dmitry Torokhov, devicetree, Xinming Hu
In-Reply-To: <CACK8Z6EAXTd07ZK3Y6Hy=7iGEY0fN91gO9Tz0NMh+shDAJoc+A@mail.gmail.com>
Rajat Jain <rajatja@google.com> writes:
> On Fri, Nov 18, 2016 at 8:21 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>
> > @@ -10,6 +10,8 @@ Required properties:
> >=C2=A0 =C2=A0 - compatible : should be one of the following:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0* "marvell,sd8897"
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0* "marvell,sd8997"
> > +=C2=A0 =C2=A0 =C2=A0* "pci11ab,2b42"
> > +=C2=A0 =C2=A0 =C2=A0* "pci1b4b,2b42"
>
> Are these correct? In v6 Rob said:
>
> "I think I already said this, but you have the vendor and product IDs
> reversed."
>
> https://patchwork.kernel.org/patch/9390225/
>=20=20=20=20
>
>
> I had responded to it:
>
>
> Hi Rob,
>
>> I think I already said this, but you have the vendor and product IDs
>> reversed.
>
> Actually Marvell has 2 vendor IDs assigned to it. In include/linux/pci_id=
s.h:
>
> #define PCI_VENDOR_ID_MARVELL 0x11ab
> #define PCI_VENDOR_ID_MARVELL_EXT 0x1b4b
>
> So in this case the compatible property describes a single product ID,
> with both possible vendor IDs.
Ok, I missed that.
BTW, please avoid using HTML. text/plain is very much preferred.
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH 0/7] rtl8xxxu: Pending patches
From: Barry Day @ 2016-11-19 2:38 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-wireless, kvalo, Larry.Finger
In-Reply-To: <wrfjbmxcb55h.fsf@redhat.com>
On Fri, Nov 18, 2016 at 09:00:10PM -0500, Jes Sorensen wrote:
> Barry Day <briselec@gmail.com> writes:
> > On Fri, Nov 18, 2016 at 04:44:21PM -0500, Jes.Sorensen@redhat.com wrote:
> >> From: Jes Sorensen <Jes.Sorensen@redhat.com>
> >>
> >> Kalle,
> >>
> >> Please find attached a number of patches for the rtl8xxxu
> >> driver.
> >>
> >> The issues reported with wpa_supplicant on 8723bu still needs further
> >> investigation.
> >>
> >
> > The patch I posted that you want tested more will also fix the
> > wpa_supplicant issue. Currently I'm looking at why the tx rate is not
> > what it should be. I feel fixing that first will be beneficial for
> > fixing any other issues.
>
> Interesting, I was thinking that might be the case. I do want to dig
> into this further to understand it better. If we use your solution I
> will want to make sure we cover both gen1 and gen2 parts.
>
> > The recent merge has made my local branch of rtl8xxxu-devel 14 commits ahead.
> > Do I need to do a reset and submit a new patch for the DWA-131 dongle?
>
> In general you need to use 'git pull --rebase' on my tree. I rebase it
> to stay in sync with Kalle's tree.
>
> The DWA-131 is the 8192eu? Sorry a bit behind and my mind is losing
> bits. If it's the patch you posted earlier I can dig it out and play
> with it - I am still catching up though, so please be patient.
>
> Cheers,
> Jes
>
>
yes it's an 8192eu.
Would you accept a patch that adds a struct device pointer to rtl8xxxu_priv
and used as the device pointer in the logging functions? Then all the messages
will start with the driver name making them easier to find.
Barry
^ permalink raw reply
* Re: [PATCH 0/7] rtl8xxxu: Pending patches
From: Jes Sorensen @ 2016-11-19 2:00 UTC (permalink / raw)
To: Barry Day; +Cc: linux-wireless, kvalo, Larry.Finger
In-Reply-To: <20161119014648.GA7140@testbox>
Barry Day <briselec@gmail.com> writes:
> On Fri, Nov 18, 2016 at 04:44:21PM -0500, Jes.Sorensen@redhat.com wrote:
>> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>>
>> Kalle,
>>
>> Please find attached a number of patches for the rtl8xxxu
>> driver.
>>
>> The issues reported with wpa_supplicant on 8723bu still needs further
>> investigation.
>>
>
> The patch I posted that you want tested more will also fix the
> wpa_supplicant issue. Currently I'm looking at why the tx rate is not
> what it should be. I feel fixing that first will be beneficial for
> fixing any other issues.
Interesting, I was thinking that might be the case. I do want to dig
into this further to understand it better. If we use your solution I
will want to make sure we cover both gen1 and gen2 parts.
> The recent merge has made my local branch of rtl8xxxu-devel 14 commits ahead.
> Do I need to do a reset and submit a new patch for the DWA-131 dongle?
In general you need to use 'git pull --rebase' on my tree. I rebase it
to stay in sync with Kalle's tree.
The DWA-131 is the 8192eu? Sorry a bit behind and my mind is losing
bits. If it's the patch you posted earlier I can dig it out and play
with it - I am still catching up though, so please be patient.
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH 0/7] rtl8xxxu: Pending patches
From: Barry Day @ 2016-11-19 1:46 UTC (permalink / raw)
To: Jes.Sorensen; +Cc: linux-wireless, kvalo, Larry.Finger
In-Reply-To: <1479505468-29383-1-git-send-email-Jes.Sorensen@redhat.com>
On Fri, Nov 18, 2016 at 04:44:21PM -0500, Jes.Sorensen@redhat.com wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> Kalle,
>
> Please find attached a number of patches for the rtl8xxxu
> driver.
>
> The issues reported with wpa_supplicant on 8723bu still needs further
> investigation.
>
The patch I posted that you want tested more will also fix the wpa_supplicant
issue.
Currently I'm looking at why the tx rate is not what it should be. I feel
fixing that first will be beneficial for fixing any other issues.
The recent merge has made my local branch of rtl8xxxu-devel 14 commits ahead.
Do I need to do a reset and submit a new patch for the DWA-131 dongle?
Barry
^ permalink raw reply
* Re: [PATCH] RFC: Universal scan proposal
From: Dmitry Shmidt @ 2016-11-18 23:53 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless
In-Reply-To: <7645397c-c9cd-f7ac-4add-fae580c485e9@broadcom.com>
On Thu, Nov 17, 2016 at 12:56 PM, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 16-11-2016 23:47, dimitrysh@google.com wrote:
>> From 68a9d37a4c7e9dc7a90a6e922cdea52737a98d66 Mon Sep 17 00:00:00 2001
>> From: Dmitry Shmidt <dimitrysh@google.com>
>> Date: Wed, 16 Nov 2016 14:27:26 -0800
>> Subject: [PATCH] RFC: Universal scan proposal
>>
>> Currently we have sched scan with possibility of various
>> intervals. We would like to extend it to support also
>> different types of scan.
>> In case of powerful wlan CPU, all this functionality
>> can be offloaded.
>> In general case FW processes additional scan requests
>> and puts them into queue based on start time and interval.
>> Once current request is fulfilled, FW adds it (if interval != 0)
>> again to the queue with proper interval. If requests are
>> overlapping, new request can be combined with either one before,
>> or one after, assuming that requests are not mutually exclusive.
>> Combining requests is done by combining scan channels, ssids,
>> bssids and types of scan result. Once combined request was fulfilled
>> it will be reinserted as two (or three) different requests based on
>> their type and interval.
>> Each request has attribute:
>> Type: connectivity / location
>
> Don't see this type in the patch below (guess it was a last minute
> addition ;-) ).
>
>> Report: none / batch / immediate
>> Request may have priority and can be inserted into
>> the head of the queue.
>> Types of scans:
>> - Normal scan
>> - Scheduled scan
>> - Hotlist (BSSID scan)
>> - Roaming
>> - AutoJoin
>
> Don't see the last one mentioned in the patch below.
>
>> Change-Id: I9f3e4c975784f1c1c5156887144d80fc5a26bffa
>> Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
>> ---
>> include/net/cfg80211.h | 37 +++++++++++++++++++++++++++++++------
>> 1 file changed, 31 insertions(+), 6 deletions(-)
>>
>> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
>> index 14b51d7..1ae2570 100644
>> --- a/include/net/cfg80211.h
>> +++ b/include/net/cfg80211.h
>> @@ -1602,8 +1602,10 @@ struct cfg80211_sched_scan_plan {
>> * cycle. The driver may ignore this parameter and start
>> * immediately (or at any other time), if this feature is not
>> * supported.
>
> At the the top of this kernel doc section it probably still refers to
> struct cfg80211_sched_scan_request.
>
>> + * @uscan_type: uscan type (scan, sched_scan, hotlist, scan_history,
>> roaming)
>> + * @uscan_results: uscan results report (none/batch/immediate)
>
> If you change the type to struct cfg80211_uscan_request it seems a bit
> redundant to prefix the field names with 'uscan_'.
>
>> */
>> -struct cfg80211_sched_scan_request {
>> +struct cfg80211_uscan_request {
>> struct cfg80211_ssid *ssids;
>> int n_ssids;
>> u32 n_channels;
>> @@ -1621,6 +1623,10 @@ struct cfg80211_sched_scan_request {
>> u8 mac_addr[ETH_ALEN] __aligned(2);
>> u8 mac_addr_mask[ETH_ALEN] __aligned(2);
>>
>> + /* universal scan fields */
>
> As the struct name changed it seems to me all fields in the struct are
> universal scan fields.
>
>> + u32 uscan_type;
>> + u32 uscan_results;
>> +
>> /* internal */
>> struct wiphy *wiphy;
>> struct net_device *dev;
>> @@ -1633,6 +1639,21 @@ struct cfg80211_sched_scan_request {
>> };
>>
>> /**
>> + * struct cfg80211_uscan_capa - universal scan capabilities
>> + *
>> + * @uscan_type: uscan type (scan, sched_scan, hotlist, scan_history,
>> roaming)
>> + * @max_ssids: max amount of ssids in sched scan
>> + * @max_hotlist: max amount of bssids in hotlist
>> + * @max_history: max amount of records in history
>> + */
>> +struct cfg80211_uscan_capa {
>> + u32 uscan_type;
>> + u32 max_ssids;
>> + u32 max_hotlist;
>> + u32 max_history;
>> +};
>> +
>> +/**
>> * enum cfg80211_signal_type - signal type
>> *
>> * @CFG80211_SIGNAL_TYPE_NONE: no signal strength information available
>> @@ -2898,10 +2919,13 @@ struct cfg80211_ops {
>> int (*set_antenna)(struct wiphy *wiphy, u32 tx_ant, u32 rx_ant);
>> int (*get_antenna)(struct wiphy *wiphy, u32 *tx_ant, u32 *rx_ant);
>>
>> - int (*sched_scan_start)(struct wiphy *wiphy,
>> + int (*uscan_get_capa)(struct wiphy *wiphy, struct net_device *dev,
>> + struct cfg80211_uscan_capa *uscan_capa);
>
> Not sure if people start worrying about the size of struct wiphy
> already, but for static information like capabilities I think a callback
> is overkill.
>
>> + int (*uscan_start)(struct wiphy *wiphy,
>> struct net_device *dev,
>> - struct cfg80211_sched_scan_request *request);
>> - int (*sched_scan_stop)(struct wiphy *wiphy, struct net_device
>> *dev);
>> + struct cfg80211_uscan_request *request);
>
> So given the two extra fields, what different driver/device behaviour is
> required, eg. if uscan_type == roaming what will be different compared
> to a normal scan.
>
>> + int (*uscan_stop)(struct wiphy *wiphy, struct net_device *dev,
>> + int uscan_id);
>
> The uscan_id is probably referring to a specific scan request started by
> uscan_start. So who hands out that id (wiphy->cookie_counter?) and how
> does the driver know about it. If cfg80211 determines the id it probably
> need to be passed in the uscan request.
>
>> int (*set_rekey_data)(struct wiphy *wiphy, struct net_device *dev,
>> struct cfg80211_gtk_rekey_data *data);
>> @@ -4305,11 +4329,12 @@ void cfg80211_scan_done(struct
>> cfg80211_scan_request *request,
>> struct cfg80211_scan_info *info);
>>
>> /**
>> - * cfg80211_sched_scan_results - notify that new scan results are
>> available
>> + * cfg80211_uscan_results - notify that new uscan results are available
>> *
>> * @wiphy: the wiphy which got scheduled scan results
>> + * @uscan_id: type of scan results
>
> Confused now. What is uscan_id here? Same as in .uscan_stop() callback?
Just to clarify - this is not a patch that is passing compilation.
It is something to discuss as a concept.
And we have several options - either have different set of functions for
different scans or to get id from start and use it for stop and notification.
>> */
>> -void cfg80211_sched_scan_results(struct wiphy *wiphy);
>> +void cfg80211_sched_scan_results(struct wiphy *wiphy, int uscan_id);
>
> should this be renamed to cfg80211_uscan_results().
>
>> /**
>> * cfg80211_sched_scan_stopped - notify that the scheduled scan has
>> stopped
>
> Also change to cfg80211_uscan_stopped()? Does it need an additional
> argument, ie. uscan_id.
Yes
> Regards,
> Arend
^ permalink raw reply
* [PATCH] ath10k: fix monitor vdev for receiving other bss frames
From: Rajkumar Manoharan @ 2016-11-18 23:10 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, rmanohar, Rajkumar Manoharan
In order to receive other BSS entries in mesh mode, Monitor vdev
is created whenever filter flag is set with OTHER_BSS. Recently
it is root caused that setting promisc filter for Mesh interface
is causing performance and stability issues. To fix this issue,
firmware will configure appropriate rxfilters by default for mesh
vdev during vdev creation. This change fixes monitor vdev creation
based on firmware IE
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.c | 1 +
drivers/net/wireless/ath/ath10k/core.h | 7 +++++++
drivers/net/wireless/ath/ath10k/mac.c | 4 +++-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 7005e2a98726..b796be1d6318 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -326,6 +326,7 @@
[ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] = "peer-flow-ctrl",
[ATH10K_FW_FEATURE_BTCOEX_PARAM] = "btcoex-param",
[ATH10K_FW_FEATURE_SKIP_NULL_FUNC_WAR] = "skip-null-func-war",
+ [ATH10K_FW_FEATURE_ALLOWS_MESH_BCAST] = "allows-mesh-bcast",
};
static unsigned int ath10k_core_get_fw_feature_str(char *buf,
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index e8decfaba5b6..179e52fbad55 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -562,6 +562,13 @@ enum ath10k_fw_features {
*/
ATH10K_FW_FEATURE_SKIP_NULL_FUNC_WAR = 15,
+ /* Firmware allow other BSS mesh broadcast/multicast frames without
+ * creating monitor interface. Appropriate rxfilters are programmed for
+ * mesh vdev by firmware itself. This feature flags will be used for
+ * not creating monitor vdev while configuring mesh node.
+ */
+ ATH10K_FW_FEATURE_ALLOWS_MESH_BCAST = 16,
+
/* keep last */
ATH10K_FW_FEATURE_COUNT,
};
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 717b2fad9a8a..56b8859d4a72 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1167,7 +1167,9 @@ static bool ath10k_mac_monitor_vdev_is_needed(struct ath10k *ar)
return false;
return ar->monitor ||
- ar->filter_flags & FIF_OTHER_BSS ||
+ (!test_bit(ATH10K_FW_FEATURE_ALLOWS_MESH_BCAST,
+ ar->running_fw->fw_file.fw_features) &&
+ (ar->filter_flags & FIF_OTHER_BSS)) ||
test_bit(ATH10K_CAC_RUNNING, &ar->dev_flags);
}
--
1.9.1
^ permalink raw reply related
* Potential deadlock BUG in drivers/net/wireless/st/cw1200/sta.c (Linux 4.9)
From: Iago Abal @ 2016-11-18 21:58 UTC (permalink / raw)
To: Kalle Valo; +Cc: Solomon Peachy, linux-wireless, netdev
Hi,
With the help of a static bug finder (EBA -
https://github.com/models-team/eba) I have found a potential deadlock
in drivers/net/wireless/st/cw1200/
sta.c. This happens due to a recursive mutex_lock on `priv->conf_mutex'.
If this is indeed a bug, I will be happy to help with a patch.
A quick (not elegant) fix could be to unlock before the call to
`cw1200_do_unjoin' in line 1174, and lock again afterwards. It seems
that `cw1200_join_complete' is always called with `priv->conf_mutex'
held. Another option could be to add a Boolean parameter to
`cw1200_do_unjoin' to choose whether this function should take the
lock itself. Yet another option would be to have a
`__cw1200_do_unjoin' that does not lock, and make `cw1200_do_unjoin' a
wrapper over this that adds the locking; `cw1200_join_complete' would
call `__cw1200_do_unjoin' instead.
Someone who is actually familiar with this code may have a better
proposal though.
The trace is as follows:
1. Function `cw1200_join_complete_work' takes the first lock in line 1189:
// see https://github.com/torvalds/linux/blob/v4.9-rc5/drivers/net/wireless/st/cw1200/sta.c#L1189
mutex_lock(& priv->conf_mutex);
2. and subsequently calls `cw1200_join_complete';
3. which calls `cw1200_do_unjoin' in line 1174;
4. and this latter function takes the lock for the second time in line 1387:
// see https://github.com/torvalds/linux/blob/v4.9-rc5/drivers/net/wireless/st/cw1200/sta.c#L1387
mutex_lock(& priv->conf_mutex);
Hope it helps!
--
iago
^ permalink raw reply
* [PATCH 5/7] rtl8xxxu: Obtain RTS rates from mac80211
From: Jes.Sorensen @ 2016-11-18 21:44 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, Jes Sorensen
In-Reply-To: <1479505468-29383-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Use the mac80211 provided rate for RTS rather than the hard coded
24Mbps as suggested by the vendor drivers.
Reported-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 6 +--
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 46 ++++++++++++++--------
2 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 08d587a..bc3c990 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1340,7 +1340,7 @@ struct rtl8xxxu_fileops {
void (*fill_txdesc) (struct ieee80211_hdr *hdr,
struct rtl8xxxu_txdesc32 *tx_desc, u32 rate,
u16 rate_flag, bool sgi, bool short_preamble,
- bool ampdu_enable);
+ bool ampdu_enable, u32 rts_rate);
int writeN_block_size;
int rx_agg_buf_size;
char tx_desc_size;
@@ -1437,11 +1437,11 @@ bool rtl8xxxu_gen2_simularity_compare(struct rtl8xxxu_priv *priv,
void rtl8xxxu_fill_txdesc_v1(struct ieee80211_hdr *hdr,
struct rtl8xxxu_txdesc32 *tx_desc, u32 rate,
u16 rate_flag, bool sgi, bool short_preamble,
- bool ampdu_enable);
+ bool ampdu_enable, u32 rts_rate);
void rtl8xxxu_fill_txdesc_v2(struct ieee80211_hdr *hdr,
struct rtl8xxxu_txdesc32 *tx_desc32, u32 rate,
u16 rate_flag, bool sgi, bool short_preamble,
- bool ampdu_enable);
+ bool ampdu_enable, u32 rts_rate);
extern struct rtl8xxxu_fileops rtl8192cu_fops;
extern struct rtl8xxxu_fileops rtl8192eu_fops;
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index a5e6ec2..a4ac557 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4762,7 +4762,7 @@ void
rtl8xxxu_fill_txdesc_v1(struct ieee80211_hdr *hdr,
struct rtl8xxxu_txdesc32 *tx_desc, u32 rate,
u16 rate_flag, bool sgi, bool short_preamble,
- bool ampdu_enable)
+ bool ampdu_enable, u32 rts_rate)
{
u16 seq_number;
@@ -4796,15 +4796,16 @@ rtl8xxxu_fill_txdesc_v1(struct ieee80211_hdr *hdr,
if (sgi)
tx_desc->txdw5 |= cpu_to_le32(TXDESC32_SHORT_GI);
+ /*
+ * rts_rate is zero if RTS/CTS or CTS to SELF are not enabled
+ */
+ tx_desc->txdw4 |= cpu_to_le32(rts_rate << TXDESC32_RTS_RATE_SHIFT);
if (rate_flag & IEEE80211_TX_RC_USE_RTS_CTS) {
- /*
- * Use RTS rate 24M - does the mac80211 tell
- * us which to use?
- */
- tx_desc->txdw4 |= cpu_to_le32(DESC_RATE_24M <<
- TXDESC32_RTS_RATE_SHIFT);
tx_desc->txdw4 |= cpu_to_le32(TXDESC32_RTS_CTS_ENABLE);
tx_desc->txdw4 |= cpu_to_le32(TXDESC32_HW_RTS_ENABLE);
+ } else if (rate_flag & IEEE80211_TX_RC_USE_CTS_PROTECT) {
+ tx_desc->txdw4 |= cpu_to_le32(TXDESC32_CTS_SELF_ENABLE);
+ tx_desc->txdw4 |= cpu_to_le32(TXDESC32_HW_RTS_ENABLE);
}
}
@@ -4816,7 +4817,7 @@ void
rtl8xxxu_fill_txdesc_v2(struct ieee80211_hdr *hdr,
struct rtl8xxxu_txdesc32 *tx_desc32, u32 rate,
u16 rate_flag, bool sgi, bool short_preamble,
- bool ampdu_enable)
+ bool ampdu_enable, u32 rts_rate)
{
struct rtl8xxxu_txdesc40 *tx_desc40;
u16 seq_number;
@@ -4849,15 +4850,19 @@ rtl8xxxu_fill_txdesc_v2(struct ieee80211_hdr *hdr,
if (short_preamble)
tx_desc40->txdw5 |= cpu_to_le32(TXDESC40_SHORT_PREAMBLE);
+ tx_desc40->txdw4 |= cpu_to_le32(rts_rate << TXDESC40_RTS_RATE_SHIFT);
+ /*
+ * rts_rate is zero if RTS/CTS or CTS to SELF are not enabled
+ */
if (rate_flag & IEEE80211_TX_RC_USE_RTS_CTS) {
- /*
- * Use RTS rate 24M - does the mac80211 tell
- * us which to use?
- */
- tx_desc40->txdw4 |= cpu_to_le32(DESC_RATE_24M <<
- TXDESC40_RTS_RATE_SHIFT);
tx_desc40->txdw3 |= cpu_to_le32(TXDESC40_RTS_CTS_ENABLE);
tx_desc40->txdw3 |= cpu_to_le32(TXDESC40_HW_RTS_ENABLE);
+ } else if (rate_flag & IEEE80211_TX_RC_USE_CTS_PROTECT) {
+ /*
+ * For some reason the vendor driver doesn't set
+ * TXDESC40_HW_RTS_ENABLE for CTS to SELF
+ */
+ tx_desc40->txdw3 |= cpu_to_le32(TXDESC40_CTS_SELF_ENABLE);
}
}
@@ -4874,7 +4879,7 @@ static void rtl8xxxu_tx(struct ieee80211_hw *hw,
struct ieee80211_sta *sta = NULL;
struct ieee80211_vif *vif = tx_info->control.vif;
struct device *dev = &priv->udev->dev;
- u32 queue, rate;
+ u32 queue, rate, rts_rate;
u16 pktlen = skb->len;
u16 seq_number;
u16 rate_flag = tx_info->control.rates[0].flags;
@@ -4974,10 +4979,17 @@ static void rtl8xxxu_tx(struct ieee80211_hw *hw,
(sta && vif && vif->bss_conf.use_short_preamble))
short_preamble = true;
+ if (rate_flag & IEEE80211_TX_RC_USE_RTS_CTS)
+ rts_rate = ieee80211_get_rts_cts_rate(hw, tx_info)->hw_value;
+ else if (rate_flag & IEEE80211_TX_RC_USE_CTS_PROTECT)
+ rts_rate = ieee80211_get_rts_cts_rate(hw, tx_info)->hw_value;
+ else
+ rts_rate = 0;
+
seq_number = IEEE80211_SEQ_TO_SN(le16_to_cpu(hdr->seq_ctrl));
- priv->fops->fill_txdesc(hdr, tx_desc, rate, rate_flag,
- sgi, short_preamble, ampdu_enable);
+ priv->fops->fill_txdesc(hdr, tx_desc, rate, rate_flag, sgi,
+ short_preamble, ampdu_enable, rts_rate);
rtl8xxxu_calc_tx_desc_csum(tx_desc);
--
2.7.4
^ permalink raw reply related
* [PATCH 6/7] rtl8xxxu: Pass tx_info to fill_txdesc in order to have access to retry count
From: Jes.Sorensen @ 2016-11-18 21:44 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, Jes Sorensen
In-Reply-To: <1479505468-29383-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
In order to obtain retry count for a given rate we need to pass the
full struct ieee80211_tx_info to the function setting the rate in he
TX descriptor.
This uncovered a huge bug where the old code would use struct
ieee80211_rate.flags to test for rate parameters, which is always
zero, instead of the flags value from struct ieee80211_tx_rate.
Time to find a brown paper bag :(
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 27 ++++----
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 71 ++++++++++++++--------
2 files changed, 60 insertions(+), 38 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index bc3c990..df551b2 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1337,10 +1337,11 @@ struct rtl8xxxu_fileops {
u32 ramask, int sgi);
void (*report_connect) (struct rtl8xxxu_priv *priv,
u8 macid, bool connect);
- void (*fill_txdesc) (struct ieee80211_hdr *hdr,
- struct rtl8xxxu_txdesc32 *tx_desc, u32 rate,
- u16 rate_flag, bool sgi, bool short_preamble,
- bool ampdu_enable, u32 rts_rate);
+ void (*fill_txdesc) (struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
+ struct ieee80211_tx_info *tx_info,
+ struct rtl8xxxu_txdesc32 *tx_desc, bool sgi,
+ bool short_preamble, bool ampdu_enable,
+ u32 rts_rate);
int writeN_block_size;
int rx_agg_buf_size;
char tx_desc_size;
@@ -1434,14 +1435,16 @@ int rtl8xxxu_parse_rxdesc24(struct rtl8xxxu_priv *priv, struct sk_buff *skb);
int rtl8xxxu_gen2_channel_to_group(int channel);
bool rtl8xxxu_gen2_simularity_compare(struct rtl8xxxu_priv *priv,
int result[][8], int c1, int c2);
-void rtl8xxxu_fill_txdesc_v1(struct ieee80211_hdr *hdr,
- struct rtl8xxxu_txdesc32 *tx_desc, u32 rate,
- u16 rate_flag, bool sgi, bool short_preamble,
- bool ampdu_enable, u32 rts_rate);
-void rtl8xxxu_fill_txdesc_v2(struct ieee80211_hdr *hdr,
- struct rtl8xxxu_txdesc32 *tx_desc32, u32 rate,
- u16 rate_flag, bool sgi, bool short_preamble,
- bool ampdu_enable, u32 rts_rate);
+void rtl8xxxu_fill_txdesc_v1(struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
+ struct ieee80211_tx_info *tx_info,
+ struct rtl8xxxu_txdesc32 *tx_desc, bool sgi,
+ bool short_preamble, bool ampdu_enable,
+ u32 rts_rate);
+void rtl8xxxu_fill_txdesc_v2(struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
+ struct ieee80211_tx_info *tx_info,
+ struct rtl8xxxu_txdesc32 *tx_desc32, bool sgi,
+ bool short_preamble, bool ampdu_enable,
+ u32 rts_rate);
extern struct rtl8xxxu_fileops rtl8192cu_fops;
extern struct rtl8xxxu_fileops rtl8192eu_fops;
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index a4ac557..04141e5 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4759,13 +4759,28 @@ static void rtl8xxxu_dump_action(struct device *dev,
* This format is used on 8188cu/8192cu/8723au
*/
void
-rtl8xxxu_fill_txdesc_v1(struct ieee80211_hdr *hdr,
- struct rtl8xxxu_txdesc32 *tx_desc, u32 rate,
- u16 rate_flag, bool sgi, bool short_preamble,
- bool ampdu_enable, u32 rts_rate)
+rtl8xxxu_fill_txdesc_v1(struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
+ struct ieee80211_tx_info *tx_info,
+ struct rtl8xxxu_txdesc32 *tx_desc, bool sgi,
+ bool short_preamble, bool ampdu_enable, u32 rts_rate)
{
+ struct ieee80211_rate *tx_rate = ieee80211_get_tx_rate(hw, tx_info);
+ struct rtl8xxxu_priv *priv = hw->priv;
+ struct device *dev = &priv->udev->dev;
+ u32 rate;
+ u16 rate_flags = tx_info->control.rates[0].flags;
u16 seq_number;
+ if (rate_flags & IEEE80211_TX_RC_MCS &&
+ !ieee80211_is_mgmt(hdr->frame_control))
+ rate = tx_info->control.rates[0].idx + DESC_RATE_MCS0;
+ else
+ rate = tx_rate->hw_value;
+
+ if (rtl8xxxu_debug & RTL8XXXU_DEBUG_TX)
+ dev_info(dev, "%s: TX rate: %d, pkt size %d\n",
+ __func__, rate, cpu_to_le16(tx_desc->pkt_size));
+
seq_number = IEEE80211_SEQ_TO_SN(le16_to_cpu(hdr->seq_ctrl));
tx_desc->txdw5 = cpu_to_le32(rate);
@@ -4800,10 +4815,10 @@ rtl8xxxu_fill_txdesc_v1(struct ieee80211_hdr *hdr,
* rts_rate is zero if RTS/CTS or CTS to SELF are not enabled
*/
tx_desc->txdw4 |= cpu_to_le32(rts_rate << TXDESC32_RTS_RATE_SHIFT);
- if (rate_flag & IEEE80211_TX_RC_USE_RTS_CTS) {
+ if (rate_flags & IEEE80211_TX_RC_USE_RTS_CTS) {
tx_desc->txdw4 |= cpu_to_le32(TXDESC32_RTS_CTS_ENABLE);
tx_desc->txdw4 |= cpu_to_le32(TXDESC32_HW_RTS_ENABLE);
- } else if (rate_flag & IEEE80211_TX_RC_USE_CTS_PROTECT) {
+ } else if (rate_flags & IEEE80211_TX_RC_USE_CTS_PROTECT) {
tx_desc->txdw4 |= cpu_to_le32(TXDESC32_CTS_SELF_ENABLE);
tx_desc->txdw4 |= cpu_to_le32(TXDESC32_HW_RTS_ENABLE);
}
@@ -4814,16 +4829,31 @@ rtl8xxxu_fill_txdesc_v1(struct ieee80211_hdr *hdr,
* This format is used on 8192eu/8723bu
*/
void
-rtl8xxxu_fill_txdesc_v2(struct ieee80211_hdr *hdr,
- struct rtl8xxxu_txdesc32 *tx_desc32, u32 rate,
- u16 rate_flag, bool sgi, bool short_preamble,
- bool ampdu_enable, u32 rts_rate)
+rtl8xxxu_fill_txdesc_v2(struct ieee80211_hw *hw, struct ieee80211_hdr *hdr,
+ struct ieee80211_tx_info *tx_info,
+ struct rtl8xxxu_txdesc32 *tx_desc32, bool sgi,
+ bool short_preamble, bool ampdu_enable, u32 rts_rate)
{
+ struct ieee80211_rate *tx_rate = ieee80211_get_tx_rate(hw, tx_info);
+ struct rtl8xxxu_priv *priv = hw->priv;
+ struct device *dev = &priv->udev->dev;
struct rtl8xxxu_txdesc40 *tx_desc40;
+ u32 rate;
+ u16 rate_flags = tx_info->control.rates[0].flags;
u16 seq_number;
tx_desc40 = (struct rtl8xxxu_txdesc40 *)tx_desc32;
+ if (rtl8xxxu_debug & RTL8XXXU_DEBUG_TX)
+ dev_info(dev, "%s: TX rate: %d, pkt size %d\n",
+ __func__, rate, cpu_to_le16(tx_desc40->pkt_size));
+
+ if (rate_flags & IEEE80211_TX_RC_MCS &&
+ !ieee80211_is_mgmt(hdr->frame_control))
+ rate = tx_info->control.rates[0].idx + DESC_RATE_MCS0;
+ else
+ rate = tx_rate->hw_value;
+
seq_number = IEEE80211_SEQ_TO_SN(le16_to_cpu(hdr->seq_ctrl));
tx_desc40->txdw4 = cpu_to_le32(rate);
@@ -4854,10 +4884,10 @@ rtl8xxxu_fill_txdesc_v2(struct ieee80211_hdr *hdr,
/*
* rts_rate is zero if RTS/CTS or CTS to SELF are not enabled
*/
- if (rate_flag & IEEE80211_TX_RC_USE_RTS_CTS) {
+ if (rate_flags & IEEE80211_TX_RC_USE_RTS_CTS) {
tx_desc40->txdw3 |= cpu_to_le32(TXDESC40_RTS_CTS_ENABLE);
tx_desc40->txdw3 |= cpu_to_le32(TXDESC40_HW_RTS_ENABLE);
- } else if (rate_flag & IEEE80211_TX_RC_USE_CTS_PROTECT) {
+ } else if (rate_flags & IEEE80211_TX_RC_USE_CTS_PROTECT) {
/*
* For some reason the vendor driver doesn't set
* TXDESC40_HW_RTS_ENABLE for CTS to SELF
@@ -4872,14 +4902,13 @@ static void rtl8xxxu_tx(struct ieee80211_hw *hw,
{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
- struct ieee80211_rate *tx_rate = ieee80211_get_tx_rate(hw, tx_info);
struct rtl8xxxu_priv *priv = hw->priv;
struct rtl8xxxu_txdesc32 *tx_desc;
struct rtl8xxxu_tx_urb *tx_urb;
struct ieee80211_sta *sta = NULL;
struct ieee80211_vif *vif = tx_info->control.vif;
struct device *dev = &priv->udev->dev;
- u32 queue, rate, rts_rate;
+ u32 queue, rts_rate;
u16 pktlen = skb->len;
u16 seq_number;
u16 rate_flag = tx_info->control.rates[0].flags;
@@ -4906,10 +4935,6 @@ static void rtl8xxxu_tx(struct ieee80211_hw *hw,
goto error;
}
- if (rtl8xxxu_debug & RTL8XXXU_DEBUG_TX)
- dev_info(dev, "%s: TX rate: %d (%d), pkt size %d\n",
- __func__, tx_rate->bitrate, tx_rate->hw_value, pktlen);
-
if (ieee80211_is_action(hdr->frame_control))
rtl8xxxu_dump_action(dev, hdr);
@@ -4963,12 +4988,6 @@ static void rtl8xxxu_tx(struct ieee80211_hw *hw,
}
}
- if (rate_flag & IEEE80211_TX_RC_MCS &&
- !ieee80211_is_mgmt(hdr->frame_control))
- rate = tx_info->control.rates[0].idx + DESC_RATE_MCS0;
- else
- rate = tx_rate->hw_value;
-
if (rate_flag & IEEE80211_TX_RC_SHORT_GI ||
(ieee80211_is_data_qos(hdr->frame_control) &&
sta && sta->ht_cap.cap &
@@ -4988,8 +5007,8 @@ static void rtl8xxxu_tx(struct ieee80211_hw *hw,
seq_number = IEEE80211_SEQ_TO_SN(le16_to_cpu(hdr->seq_ctrl));
- priv->fops->fill_txdesc(hdr, tx_desc, rate, rate_flag, sgi,
- short_preamble, ampdu_enable, rts_rate);
+ priv->fops->fill_txdesc(hw, hdr, tx_info, tx_desc, sgi, short_preamble,
+ ampdu_enable, rts_rate);
rtl8xxxu_calc_tx_desc_csum(tx_desc);
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox