linux-kernel - Re: [PATCH] staging: rtl8712: switch to common ieee80211 headers

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 2 Jun 2020 16:58:46 +0100
From:   Pascal Terjan <pterjan@...gle.com>
To:     Larry Finger <Larry.Finger@...inger.net>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Florian Schilhabel <florian.c.schilhabel@...glemail.com>,
        devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: rtl8712: switch to common ieee80211 headers

On Tue, 2 Jun 2020 at 15:57, Larry Finger <Larry.Finger@...inger.net> wrote:
>
> On 6/1/20 3:24 PM, Pascal Terjan wrote:
> > This patch switches to <linux/ieee80211.h> and <net/cfg80211.h> and
> > deletes a lot of duplicate definitions plus many unused ones.
> >
> > Non obvious changes:
> > - struct ieee80211_ht_cap is different enough that I preferred to keep
> >    (and rename) it for now.
> > - mcs_rate in translate_scan was not read after being set, so I deleted
> >    that part rather than using the renamed struct
> > - WLAN_CAPABILITY_BSS is replaced with WLAN_CAPABILITY_ESS which is the
> >    corresponding one with same value
> >
> > Signed-off-by: Pascal Terjan <pterjan@...gle.com>
>
> This patch does not apply to the staging repo, current mainline, or
> wireless-drivers-next. Where did you intend it to go? Staging is the correct tree.

It was against staging-testing as there is a (trivial) merge conflict
in there with https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing&id=2aaeaaff1ae21b2817256435c7fc0095eeda61ae
which is also in staging-next
What is the best practice in such case?

Thanks to kbuild test robot I found that it is failing to build there
because I forgot to add a dependency on CFG80211 in Kconfig, so I will
need to send a v2.