On 23.05.2018 09:58, Arend van Spriel wrote:
On 5/22/2018 3:18 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
Some features supported by firmware aren't advertised and there is no
way for a driver to query them. This includes e.g. monitor mode details.
Some firmwares support tagging monitor fram
Am 23.05.2018 um 12:39 schrieb Johannes Berg:
On Wed, 2018-05-23 at 16:09 +0530, Manikanta Pubbisetty wrote:
+ * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting
+ * frames encrypted in software, only valid when SW_CRYPTO_CONTROL
+ * is enabled. Based on this flag,
Arnd Bergmann writes:
> On Fri, May 11, 2018 at 2:20 PM, Kalle Valo wrote:
>> Stephen Rothwell writes:
>>
>>> After merging the mac80211-next tree, today's linux-next build (arm_multi
>>> v7_defconfig) produced this warning:
>>>
>>> drivers/net/wireless/marvell/mwifiex/uap_event.c: In function
I realize this is a development mailinglist and not a support forum, but I'm
really at the end of my rope here.
If someone can get this working, I'll buy them a nice lunch if they're ever
near Cincinnati.
I've tried booting alternative distros to see if it is a software problem, but
no distro
Commit d4b4aaba515a ("staging: wilc1000: fix line over 80 characters in
host_int_parse_join_bss_param()") introduced a bug by not keeping the
rates_no value while parsing ies elements.
It also increments auth_total_cnt as a pointer instead of its reference.
This commit fixes the bug by passing ref
On Wed, May 23, 2018 at 06:25:49PM +0200, Erik Stromdahl wrote:
>
>
> On 05/22/2018 11:15 PM, Niklas Cassel wrote:
>
>
> > >
> > > Earlier we observed performance issues in calling push_pending from each
> > > tx completion. IMHO this change may introduce the same problem again.
> >
> > I pre
On Thu, May 24, 2018 at 12:15:08AM +0200, Niklas Cassel wrote:
> This problem cannot be reproduced on low-latency devices, e.g. pci,
> since they call ath10k_mac_tx_push_pending() from
> ath10k_htt_txrx_compl_task(). ath10k_htt_txrx_compl_task() is not called
> on high-latency devices.
> Fix the pr
When running iperf on ath10k SDIO, TX can stop working:
iperf -c 192.168.1.1 -i 1 -t 20 -w 10K
[ 3] 0.0- 1.0 sec 2.00 MBytes 16.8 Mbits/sec
[ 3] 1.0- 2.0 sec 3.12 MBytes 26.2 Mbits/sec
[ 3] 2.0- 3.0 sec 3.25 MBytes 27.3 Mbits/sec
[ 3] 3.0- 4.0 sec 655 KBytes 5.36 Mbits/sec
[ 3]
On Fri, May 11, 2018 at 2:20 PM, Kalle Valo wrote:
> Stephen Rothwell writes:
>
>> After merging the mac80211-next tree, today's linux-next build (arm_multi
>> v7_defconfig) produced this warning:
>>
>> drivers/net/wireless/marvell/mwifiex/uap_event.c: In function
>> 'mwifiex_process_uap_event':
From: Johannes Berg
Date: Wed, 23 May 2018 14:14:31 +0200
> Here's a new version of the pull request for net-next, now
> with the stack size fixes included, which were the reason I
> withdrew my earlier one. Other things are also included all
> over the map.
>
> Please pull and let me know if th
From: Kalle Valo
Date: Tue, 22 May 2018 17:28:11 +0300
> here's a pull request to net tree for 4.17. Please let me know if you
> have any problems.
Pulled, thanks Kalle.
On 2018-05-23 09:25, Erik Stromdahl wrote:
On 05/22/2018 11:15 PM, Niklas Cassel wrote:
[...]
Perhaps it would be possible to call ath10k_mac_tx_push_pending()
from the equivalent to ath10k_htt_txrx_compl_task(),
but from SDIO's point of view.
An equivalent for SDIO would most likely be
*ath
* Reizer, Eyal [180523 12:45]:
> >
> > >
> > > Here's a modified version of your patch, does that put wlcore to
> > > idle with wowlan during suspend for you?
> > >
> >
> > Still no joy.
> > It suspends/resumes ok but leaves the firmware disabled from entering ELP.
>
> Spent some time on it tod
On 05/22/2018 11:15 PM, Niklas Cassel wrote:
Earlier we observed performance issues in calling push_pending from each
tx completion. IMHO this change may introduce the same problem again.
I prefer functional TX over performance issues,
but I agree that it is unfortunate that SDIO doesn't u
On 22.05.2018 19:49, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in netdev_err error message
>
> Signed-off-by: Colin Ian King
Reviewed-by: Claudiu Beznea
> ---
> drivers/staging/wilc1000/host_interface.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletio
Ganapathi Bhat writes:
> Hi Kalle,
>
>> Arend van Spriel writes:
>>
>> > On 5/23/2018 9:54 AM, Kalle Valo wrote:
>> >> Ganapathi Bhat writes:
>> >>
>> >>> In V2:
>> >>>
>> >>> return ret;
>> >>> }
>> >>> +EXPORT_SYMBOL_GPL(mwifiex_send_cmd);
>> >>>
>> >>> Instead of exporting 'mwifie
Arend Van Spriel wrote:
> The only user of ALLFFMAC is the flowring module so no need to
> expose it in a header file.
>
> Reviewed-by: Hante Meuleman
> Reviewed-by: Pieter-Paul Giesberts
> Reviewed-by: Franky Lin
> Signed-off-by: Arend van Spriel
6 patches applied to wireless-drivers-next.
From: Johannes Berg
Date: Wed, 23 May 2018 11:47:57 +0200
> Just another handful of fixes as we wind down towards the
> merge window.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Johannes.
Please don't tell me you will soon queue up a patch that
limits wiphy names to
From: Johannes Berg
The arguments should be (# of elements, size of each) instead
of the other way around, which really ends up being mostly
equivalent but smatch complains about it, so swap them.
Signed-off-by: Johannes Berg
---
net/wireless/util.c | 5 +++--
1 file changed, 3 insertions(+),
Sure Johannes, I will send another version of patch.
On 2018-05-23 15:30, Johannes Berg wrote:
On Thu, 2018-03-08 at 12:49 +0530, Balaji Pothunoori wrote:
This patch is to display the average ack rssi for data
frames. "avg ack signal" field diplay limited by host based on
firmware capablities.
>
> >
> > Here's a modified version of your patch, does that put wlcore to
> > idle with wowlan during suspend for you?
> >
>
> Still no joy.
> It suspends/resumes ok but leaves the firmware disabled from entering ELP.
Spent some time on it today and looks like adding calls to
pm_generic_runtim
Hi Dave,
Here's a new version of the pull request for net-next, now
with the stack size fixes included, which were the reason I
withdrew my earlier one. Other things are also included all
over the map.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes
Hi Kalle,
> Arend van Spriel writes:
>
> > On 5/23/2018 9:54 AM, Kalle Valo wrote:
> >> Ganapathi Bhat writes:
> >>
> >>> In V2:
> >>>
> >>> return ret;
> >>> }
> >>> +EXPORT_SYMBOL_GPL(mwifiex_send_cmd);
> >>>
> >>> Instead of exporting 'mwifiex_send_cmd' we can prepare a wrapper for
On Wed, 2018-03-28 at 12:05 -0700, Alexei Starovoitov wrote:
> fix iwlwifi_dev_ucode_error tracepoint to pass pointer to a table
> instead of all 17 arguments by value.
> dvm/main.c and mvm/utils.c have 'struct iwl_error_event_table'
> defined with very similar yet subtly different fields and offse
On 5/23/2018 4:09 PM, Johannes Berg wrote:
On Wed, 2018-05-23 at 16:09 +0530, Manikanta Pubbisetty wrote:
+ * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting
+ * frames encrypted in software, only valid when SW_CRYPTO_CONTROL
+ * is enabled. Based on this flag, mac
On Wed, 2018-05-23 at 16:09 +0530, Manikanta Pubbisetty wrote:
> > > > > + * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of
> > > > > transmitting
> > > > > + * frames encrypted in software, only valid when
> > > > > SW_CRYPTO_CONTROL
> > > > > + * is enabled. Based on this flag,
+ * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting
+ * frames encrypted in software, only valid when SW_CRYPTO_CONTROL
+ * is enabled. Based on this flag, mac80211 can allow/disallow VLAN
+ * operations in the BSS.
Based on the name and initial description, thi
add pci_disable_device in error handling while init_atmel_card failed.
Signed-off-by: YueHaibing
---
drivers/net/wireless/atmel/atmel_pci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/atmel/atmel_pci.c
b/drivers/net/wireless/atmel/atmel_pci.c
inde
://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/brcmfmac-allow-specifying-features-per-firmware-version/20180523-160546
base:
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git
master
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
Hi Kalle,
On Friday, May 18, 2018 01:28 PM, Kalle Valo wrote:
Daniel Mack writes:
On Wednesday, May 16, 2018 04:08 PM, Daniel Mack wrote:
Hence I believe that some sort of firmware internal buffer is overrun if
too many SMD requests fly in in a short amount of time. The firmware
does, howeve
On Thu, 2018-03-08 at 12:49 +0530, Balaji Pothunoori wrote:
> This patch is to display the average ack rssi for data
> frames. "avg ack signal" field diplay limited by host based on
> firmware capablities.
This doesn't compile, please respin (and you could fix the "average"
typo in the subject)
j
On Tue, 2018-05-22 at 14:45 +0530, Venkateswara Naralasetty wrote:
> This patch provides support to send accumulated survey data to
> user if low level drivers provides non-accumulated survey data.
I think the commit log should say what you need this for?
It's simultaneously a new flag, and a lot
On Mon, 2018-05-21 at 12:12 +0530, Manikanta Pubbisetty wrote:
> > Do you know why it actually broke it? I mean, we should've turned off
> > the strict requirement for sw crypto control only for the GTK, and that
> > shouldn't matter so much?
>
> With the change db3bdcb9c3ff, AP/VLAN support is ad
Hi Dave,
Just another handful of fixes as we wind down towards the
merge window.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 6caf9fb3bda17df59de4ed6ed4950c43ca1361e3:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf (20
On Sat, 2018-05-19 at 01:06 +0530, Manikanta Pubbisetty wrote:
> Sometimes, it is required to stop the transmissions momentarily and
> resume it later; stopping the txqs becomes very critical in scenarios where
> the packet transmission has to be ceased completely. For example, during
> the hardwar
Arend van Spriel writes:
> On 5/23/2018 9:54 AM, Kalle Valo wrote:
>> Ganapathi Bhat writes:
>>
>>> In V2:
>>>
>>> return ret;
>>> }
>>> +EXPORT_SYMBOL_GPL(mwifiex_send_cmd);
>>>
>>> Instead of exporting 'mwifiex_send_cmd' we can prepare a wrapper for
>>> the command 'MWIFIEX_IFACE_WO
On 5/23/2018 9:54 AM, Kalle Valo wrote:
Ganapathi Bhat writes:
In V2:
return ret;
}
+EXPORT_SYMBOL_GPL(mwifiex_send_cmd);
Instead of exporting 'mwifiex_send_cmd' we can prepare a wrapper for
the command 'MWIFIEX_IFACE_WORK_DEVICE_DUMP' in mwifiex module. Let me
know if we can send
Sushant Kumar Mishra wrote:
> From: Sanjay Konduri
>
> Observed crash in some scenarios when assertion has occurred,
> this is because hw structure is freed and is tried to get
> accessed in some functions where null check is already
> present. So, avoided the crash by making the hw to NULL aft
Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> This allows reading all capabilities as reported by a firmware. They are
> printed using native (raw) names, just like developers like it the most.
> It's how firmware reports support for various features, e.g. supported
> modes, supported standards
Xinming Hu wrote:
> Correct snr/nr/rssi data index to avoid possible buffer underflow.
>
> Signed-off-by: Xinming Hu
Patch applied to wireless-drivers-next.git, thanks.
30bfce0b63fa mwifiex: correct histogram data with appropriate index
--
https://patchwork.kernel.org/patch/10408353/
https
On 5/22/2018 3:18 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
Some features supported by firmware aren't advertised and there is no
way for a driver to query them. This includes e.g. monitor mode details.
Some firmwares support tagging monitor frames, some build radiotap
header but there is no
Felix Fietkau wrote:
> During scans, mac80211 frequently switches back to the home channel to
> minimize interruption of ongoing traffic. Keep regular tx queues active
> during that time.
>
> Signed-off-by: Felix Fietkau
5 patches applied to wireless-drivers-next.git, thanks.
89bc67e3a93a mt7
Felix Fietkau wrote:
> For encryption to work properly, the BSS index needs to be initialized
> for the WCID entry used for the interface.
>
> Signed-off-by: Felix Fietkau
2 patches applied to wireless-drivers-next.git, thanks.
d98fb328ad10 mt76: fix sending encrypted broadcast packets for se
Lorenzo Bianconi wrote:
> According to 802.11-2007 17.3.8.6 (slot time), the slot time should
> be increased by 3 us * coverage class. Taking into account coverage
> class in slot time configuration allows to increase by an order of
> magnitude the throughput on a 4Km link in a noisy environment
Ganapathi Bhat writes:
> In V2:
>
> return ret;
> }
> +EXPORT_SYMBOL_GPL(mwifiex_send_cmd);
>
> Instead of exporting 'mwifiex_send_cmd' we can prepare a wrapper for
> the command 'MWIFIEX_IFACE_WORK_DEVICE_DUMP' in mwifiex module. Let me
> know if we can send a follow up.
So what's the
Hi Denis,
> > I'm not sure. It still indicates that a hidden SSID was found, and in
> > general even a real SSID on the same BSSID doesn't indicate that this
> > was the only hidden SSID ...
>
> Right, but you still get that info conveyed through the Beacon IEs
> elements on the second/third/etc
>
> Here's a modified version of your patch, does that put wlcore to
> idle with wowlan during suspend for you?
>
Still no joy.
It suspends/resumes ok but leaves the firmware disabled from entering ELP.
You can see the log below with some prints added to wlcore_runtime_suspend()
And wlcore_runti
47 matches
Mail list logo