On Fr, 2016-08-19 at 13:03 +0300, Kalle Valo wrote:
> Actually, I see two patches which might be related but not identical:
>
> ath9k: fix client mode beacon configuration
> https://patchwork.kernel.org/patch/9247699/
>
> ath9k: Fix beacon configuration assertion failure
> https://patchwork.kerne
On Sunday, August 21, 2016 4:31:03 PM CEST Martin Blumenstingl wrote:
> +pci {
> + pcie@0 {
> + reg = <0 0 0 0 0>;
It's not clear what these two nodes refer to in the example. Is the top-level
node the PCI host bridge, and the second node the first PCIe port?
Maybe add the pro
Various wil6210 fixes
Lior David (4):
wil6210: fix protection of wil->scan_request
wil6210: align to latest auto generated wmi.h
wil6210: extract firmware capabilities from FW file
wil6210: extract firmware version from file header
drivers/net/wireless/ath/wil6210/cfg80211.c | 3 +
dri
From: Lior David
Currently the places that check wil->scan_request and
call cfg80211_scan_done are not consistently protected,
so there is a risk that cfg80211_scan_done will be called
with NULL scan_request, causing a kernel crash.
Fix this by using p2p_wdev_mutex in few other places
that access
From: Lior David
Align to latest version of the auto generated wmi file
describing the interface with FW.
Signed-off-by: Lior David
Signed-off-by: Maya Erez
---
drivers/net/wireless/ath/wil6210/wmi.h | 292 +
1 file changed, 292 insertions(+)
diff --git a/driv
From: Lior David
When driver is loaded, extract a capabilities record
from the FW file. This record contains bits indicating
which optional features are supported by this FW.
The driver can use this information to determine
which functionality to support and/or expose to user
space.
The extractio
From: Lior David
Currently the FW version is taken from the sw_version field
of the FW ready event. This version is based on internal
version control revision and it is difficult to map to actual
FW version.
Fix this by using the actual FW version stored in the FW file
header record.
Signed-off-
On Fri, 19 Aug 2016 21:02:02 +0200, Arend Van Spriel wrote:
> On 19-8-2016 18:44, Jakub Kicinski wrote:
> > Use the newly added linux/bitfield.h.
> >
> > Reviewed-by: Dinan Gunawardena
> > Signed-off-by: Jakub Kicinski
> > ---
> > drivers/net/wireless/mediatek/mt7601u/dma.c | 2 +-
> > dri
On Sunday, August 21, 2016 4:49:02 PM CEST Martin Blumenstingl wrote:
> This replaces a magic number with a named #define. Additionally it
> removes two "eeprom format" specific #defines for the "big endianness"
> bit which are the same on all eeprom formats.
>
Looks good, but missing a Signed-of
On Sunday, August 21, 2016 4:49:03 PM CEST Martin Blumenstingl wrote:
> We will default to the system's native endianness for the eepmisc value.
> This may be overwritten by the actual calibration data. If it is not
> overwritten we interpret the template data in it's native endianness,
> meaning t
On Sunday, August 21, 2016 4:49:06 PM CEST Martin Blumenstingl wrote:
> +- qca,check-eeprom-endianness: When enabled, the driver checks if the
> + endianness of the EEPROM (using two checks,
> + one is based on the two magic bytes at the
>
On Mon, Aug 22, 2016 at 1:47 PM, Arnd Bergmann wrote:
> On Sunday, August 21, 2016 4:49:03 PM CEST Martin Blumenstingl wrote:
>> We will default to the system's native endianness for the eepmisc value.
>> This may be overwritten by the actual calibration data. If it is not
>> overwritten we interp
Hello,
After I sent the following patch a few weeks ago, I have not received
any feedback. Could you please review it and tell me what I may have
done wrong?
Thanks,
Nicolas
On 05/08/16 22:34, Nicolas Iooss wrote:
> The struct cfg80211_pmksa defines its bssid field as:
>
> const u8 *bssid;
On 22 August 2016 at 15:03, Nicolas Iooss wrote:
> After I sent the following patch a few weeks ago, I have not received
> any feedback. Could you please review it and tell me what I may have
> done wrong?
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#checking_sta
Benjamin Berg writes:
> On Fr, 2016-08-19 at 13:03 +0300, Kalle Valo wrote:
>> Actually, I see two patches which might be related but not identical:
>>
>> ath9k: fix client mode beacon configuration
>> https://patchwork.kernel.org/patch/9247699/
>>
>> ath9k: Fix beacon configuration assertion f
> + /* examine state machine */
> + mutex_lock(&sta->ampdu_mlme.mtx);
> +
> /* make sure the size doesn't exceed the maximum supported
> by the hw */
> - if (buf_size > local->hw.max_rx_aggregation_subframes)
> - buf_size = local->hw.max_rx_aggregation_subframes;
> +
The ability to change the max_rx_aggregation frames is useful
in cases of IOP.
There exist some devices (latest mobile phones and some AP's)
that tend to not respect a BA sessions maximum size (in Kbps).
These devices won't respect the AMPDU size that was negotiated during
associasion (even though
Hello there,
linux-4.8-rc3/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c:3533]:
(style) Condition 'pBtMgnt.ExtConfig.HCIExtensionVer>=1' is always
true
Source code is
if (pBtMgnt->ExtConfig.HCIExtensionVer < 1) {
} else if (pBtMgnt->ExtConfig.HCIExtensionVer >=
On Mon, Aug 22, 2016 at 03:07:44PM +0100, David Binderman wrote:
> Hello there,
>
> linux-4.8-rc3/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c:3533]:
> (style) Condition 'pBtMgnt.ExtConfig.HCIExtensionVer>=1' is always
> true
>
> Source code is
>
> if (pBtMgnt->ExtConfig.HCIExtens
Johannes Berg writes:
>> well, we're getting there. the results of both patch attempts were
>> really nice, and brought encrypted performance with fq back into line
>> with unencrypted. Still running crypted tests as I write...
>>
>> So fixing TKIP would be next, forcing the AP to use that? What
On Monday, August 22, 2016 1:56:46 PM CEST Martin Blumenstingl wrote:
> On Mon, Aug 22, 2016 at 1:47 PM, Arnd Bergmann wrote:
> > On Sunday, August 21, 2016 4:49:03 PM CEST Martin Blumenstingl wrote:
> >> We will default to the system's native endianness for the eepmisc value.
> >> This may be ove
Larry Finger writes:
> Some RTL8821AE devices sold in Great Britain have the country code of
> 0x25 encoded in their EEPROM. This value is not tested in the routine
> that establishes the regulatory info for the chip. The fix is to set
> this code to have the same capabilities as the EU countries
Toke Høiland-Jørgensen writes:
> This switches ath9k over to using the mac80211 intermediate software
> queueing mechanism for data packets. It removes the queueing inside the
> driver, except for the retry queue, and instead pulls from mac80211 when
> a packet is needed. The retry queue is used
Arend van Spriel writes:
> On 20-08-16 18:43, SF Markus Elfring wrote:
>> From: Markus Elfring
>> Date: Sat, 20 Aug 2016 18:35:43 +0200
>>
>> A few update suggestions were taken into account
>> from static source code analysis.
>
> Is it worth touching this old stuff especially when you are not
Felix Fietkau wrote:
> For pure station mode, iter_data.primary_beacon_vif was used and passed
> to ath_beacon_config, but not set to the station vif.
> This was causing the following warning:
>
> [ 100.310919] [ cut here ]
> [ 100.315683] WARNING: CPU: 0 PID: 7 at
> co
"Mishol, Guy" writes:
> Kalle/Thomas,
> Thanks for your feedback.
Please don't top most, it makes using patchwork difficult and is
annoying to the readers.
> This time sync support is different from the one that mac80211
> maintains with mesh peers. This time sync is mostly used by upper
> laye
Felix Fietkau wrote:
> A station pointer can be passed to the driver on tx, before it has been
> marked as associated. Since ath9k_sta_state was initializing the entry
> too late, it resulted in some spurious crashes.
>
> Fixes: df3c6eb34da5 ("ath9k: Use sta_state() callback")
> Cc: sta...@vger.k
Kalle Valo writes:
> Toke Høiland-Jørgensen writes:
>
>> This switches ath9k over to using the mac80211 intermediate software
>> queueing mechanism for data packets. It removes the queueing inside the
>> driver, except for the retry queue, and instead pulls from mac80211 when
>> a packet is need
On Mon, 2016-08-22 at 18:49 +0300, Kalle Valo wrote:
> Arend van Spriel writes:
[]
> But yeah, not really sure what to do with these obsolete drivers like
> hostap, ray_cs and wl3501.
Maybe marking sections obsolete in MAINTAINERS could
flag some "shouldn't touch this" warning for old code
in che
On Mon, 22 Aug 2016, Kalle Valo wrote:
> Benjamin Berg writes:
>
>> On Fr, 2016-08-19 at 13:03 +0300, Kalle Valo wrote:
>>> Actually, I see two patches which might be related but not identical:
>>>
>>> ath9k: fix client mode beacon configuration
>>> https://patchwork.kernel.org/patch/9247699/
>>
Toke Høiland-Jørgensen writes:
> Kalle Valo writes:
>
>> Toke Høiland-Jørgensen writes:
>>
>>> This switches ath9k over to using the mac80211 intermediate software
>>> queueing mechanism for data packets. It removes the queueing inside the
>>> driver, except for the retry queue, and instead pul
Kalle Valo writes:
> Toke Høiland-Jørgensen writes:
>
>> Kalle Valo writes:
>>
>>> Toke Høiland-Jørgensen writes:
>>>
This switches ath9k over to using the mac80211 intermediate software
queueing mechanism for data packets. It removes the queueing inside the
driver, except for t
Use get_maintainer to check the status of individual files.
If "obsolete", suggest leaving the files alone.
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 14 ++
1 file changed, 14 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4de3cc4..df5e9d
From: Colin Ian King
Trivial fix to spelling mistake in dev_err message.
Signed-off-by: Colin Ian King
---
drivers/net/wireless/zydas/zd1211rw/zd_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/zydas/zd1211rw/zd_usb.c
b/drivers/net/wireless/zydas
On 22-8-2016 12:52, Jakub Kicinski wrote:
> On Fri, 19 Aug 2016 21:02:02 +0200, Arend Van Spriel wrote:
>> On 19-8-2016 18:44, Jakub Kicinski wrote:
>>> Use the newly added linux/bitfield.h.
>>>
>>> Reviewed-by: Dinan Gunawardena
>>> Signed-off-by: Jakub Kicinski
>>> ---
[snip]
>>> diff --git a
On 08/22/2016 10:36 AM, Kalle Valo wrote:
Larry Finger writes:
Some RTL8821AE devices sold in Great Britain have the country code of
0x25 encoded in their EEPROM. This value is not tested in the routine
that establishes the regulatory info for the chip. The fix is to set
this code to have the
Some RTL8821AE devices sold in Great Britain have the country code of
0x25 encoded in their EEPROM. This value is not tested in the routine
that establishes the regulatory info for the chip. The fix is to set
this code to have the same capabilities as the EU countries. In addition,
the channels all
On 22-8-2016 15:03, Nicolas Iooss wrote:
> Hello,
>
> After I sent the following patch a few weeks ago, I have not received
> any feedback. Could you please review it and tell me what I may have
> done wrong?
Nothing. People went on vacation :-)
> Thanks,
> Nicolas
>
> On 05/08/16 22:34, Nicolas
On Mon, Aug 22, 2016 at 5:31 PM, Arnd Bergmann wrote:
> On Monday, August 22, 2016 1:56:46 PM CEST Martin Blumenstingl wrote:
>> On Mon, Aug 22, 2016 at 1:47 PM, Arnd Bergmann wrote:
>> > On Sunday, August 21, 2016 4:49:03 PM CEST Martin Blumenstingl wrote:
>> >> We will default to the system's n
> @@ -2289,6 +2299,10 @@ sub process {
> }
>
> if ($found_file) {
> + if (is_maintained_obsolete($realfile)) {
> + WARN("OBSOLETE",
> + "$realfile is marked as 'obsolete' in the
> MAINTAI
On Mon, 2016-08-22 at 22:50 +0200, SF Markus Elfring wrote:
> > @@ -2289,6 +2299,10 @@ sub process {
> > }
> >
> > if ($found_file) {
> > + if (is_maintained_obsolete($realfile)) {
> > + WARN("OBSOLETE",
> > +
On Mon, 22 Aug 2016 21:19:41 +0200, Arend Van Spriel wrote:
> On 22-8-2016 12:52, Jakub Kicinski wrote:
> > On Fri, 19 Aug 2016 21:02:02 +0200, Arend Van Spriel wrote:
> >> On 19-8-2016 18:44, Jakub Kicinski wrote:
> >>> Use the newly added linux/bitfield.h.
> >>>
> >>> Reviewed-by: Dinan Gunaw
Dear Friend,
Your contact details came to me by recommendation, I am interested in investing
in your country and I believe you have the capabilities of providing the needed
assistance, solutions and advise in actualizing this, Let me know if you are
willing to understake this task for me so we
The AE1200 comes with different revisions of the BCM43235 chipset,
but all have the same USB ID. Only revision 3 can be supported.
Signed-off-by: Ismael Luceno
---
Changes since v1:
- Keep the long device ID in a single line.
- Added desc. about supported devices.
drivers/net/wireless/broadco
44 matches
Mail list logo
