Previously, the status parameter to cfg80211_connect_result() was
documented as using WLAN_STATUS_UNSPECIFIED_FAILURE (1) when the real
status code for the failure is not known. This value can be used by an
AP (and often is) and as such, user space cannot distinguish between
explicitly rejected
On Monday 30 May 2016 08:52 AM, Stephen Rothwell wrote:
Hi all,
Changes since 20160527:
Hi All,
I have just built and booted with next-20160530 and my dmesg is full of
warnings from ath9k. Last kernel tested was v4.6 and there was no
problem with that.
The traces are like:
Call Trace
On 05/30/2016 10:26 AM, Arnd Bergmann wrote:
There are nine copies of the _rtl88ee_read_adapter_info() function,
and most but not all of them cause a build warning in some configurations:
rtl8192de/hw.c: In function '_rtl92de_read_adapter_info':
rtl8192de/hw.c:1767:12: error: 'hwinfo' may be
There are nine copies of the _rtl88ee_read_adapter_info() function,
and most but not all of them cause a build warning in some configurations:
rtl8192de/hw.c: In function '_rtl92de_read_adapter_info':
rtl8192de/hw.c:1767:12: error: 'hwinfo' may be used uninitialized in this
function
Michal Kazior writes:
>> +void ath_debug_tx_airtime(struct ath_softc *sc,
>> + struct ath_node *an,
>> + struct ath_tx_status *ts)
>> +{
>> + struct ath_airtime_stats *astats;
>> +
>> + rcu_read_lock();
>> +
>>
On 26 May 2016 at 15:50, Toke Høiland-Jørgensen wrote:
> This is my attempt to add per-station airtime usage accounting to ath9k.
> For now I just export it to a new debugfs entry, but my plan is to use
> it to make (station) scheduling decisions. However, before attempting
> that I
On Friday 27 May 2016 12:44:52 Valo, Kalle wrote:
[...]
> > But maybe I should add that the results with the original AP147 firmware
> > also
> > wasn't better.
>
> That doesn't sound good. Maybe a calibration issue?
Maybe but I don't have a different card to compare it to.
[...]
> I pushed a
Hi Javier,
2016-05-27 16:18 GMT+02:00 Javier Martinez Canillas :
> Hello,
>
> While booting a system with a mwifiex WiFi card, I noticed the following
> missleading error message:
>
> [ 12.480042] mwifiex_sdio mmc2:0001:1: sdio platform data not available
>
> This error
> This looks right to me, but doesn't ether_addr_copy() have alignment
> requirements? Could someone more familiar with that review these
> changes to ensure they're met?
Thanks for catching this.
The requirement is to be __aligned(2). I've added 4 instances of
ether_addr_copy with 8 addresses as
Hi All,
On Mon, May 30, 2016 at 12:53 PM, Kirtika Ruchandani
wrote:
> This patch fixes the following spacing issues reported
> by checkpatch.pl -
> - space preferred around that
> - no space needed after cast.
> - Alignment should match open parenthesis
> - suspect
Hi Kirtika,
On Mon, May 30, 2016 at 4:04 PM, Kirtika Ruchandani
wrote:
>> Adding the brackets around the & expression doesn't look spacing
>> related to me. What's the exact warning this is fixing?
>
> From the commit message - "This patch also contains two hunks to
> Adding the brackets around the & expression doesn't look spacing
> related to me. What's the exact warning this is fixing?
>From the commit message - "This patch also contains two hunks to fix
'line over 80 characters',
that are spacing related". This is the second hunk, the first being
the
12 matches
Mail list logo