netdev - Re: iwlwifi warnings in 5.5-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5d82fa60fa8170c6a41e87650785ba008da11826.camel@sipsolutions.net>
Date:   Wed, 11 Dec 2019 22:19:17 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     Toke Høiland-Jørgensen <toke@...hat.com>,
        Jens Axboe <axboe@...nel.dk>,
        Emmanuel Grumbach <emmanuel.grumbach@...el.com>,
        Luca Coelho <luciano.coelho@...el.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Steve French <smfrench@...il.com>
Cc:     "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>
Subject: Re: iwlwifi warnings in 5.5-rc1

On Wed, 2019-12-11 at 15:55 +0100, Toke Høiland-Jørgensen wrote:
> Johannes Berg <johannes@...solutions.net> writes:
> 
> > On Wed, 2019-12-11 at 15:09 +0100, Toke Høiland-Jørgensen wrote:
> > > If we're doing this on a per-driver basis, let's make it a proper
> > > NL80211_EXT_FEATURE and expose it to userspace; that way users can at
> > > least discover if it's supported on their device. I can send a patch
> > > adding that...
> > 
> > Sure. Just didn't get to that yet, but if you want to send a patch
> > that's very welcome. I have to run out now, will be back in the evening
> > at most.
> 
> Patch here (for those not following linux-wireless):
> https://patchwork.kernel.org/project/linux-wireless/list/?series=215107

Thanks!

Maybe I should roll that into a single patch so it's actually easier to
apply as a bugfix while keeping ath10k on AQL for 5.5, otherwise it
could be argued that the ath10k patch is a feature for -next ...

> > > Maybe we should untangle this from airtime_flags completely, since if we
> > > just use the flags people could conceivably end up disabling it by
> > > mistake, couldn't they?
> > 
> > Yes, that sounds like a good plan, now I was wondering why it's there
> > anyway.
> 
> Convenience, I think :)

:)

johannes