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]
Message-ID: <CAANdO=KBPh81Jaxhta8k3ipnwWbr5xdhTuRW6GNEZsTTpyMjXQ@mail.gmail.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ