Re: [PATCH 0/6] brcmfmac: fix 160MHz support and monitor mode

[Kalle Valo <kvalo@codeaurora.org>]

Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> writes:

> On Mon, 25 Jun 2018 at 10:31, Arend van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>>
>> On 6/25/2018 6:40 AM, Rafa=C5=82 Mi=C5=82ecki wrote:
>> > On Sun, 24 Jun 2018 at 13:48, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.co=
m> wrote:
>> >> On Fri, 22 Jun 2018 at 20:45, Arend van Spriel
>> >> <arend.vanspriel@broadcom.com> wrote:
>> >>> Here a couple of patches in preparation of monitor mode support. It
>> >>> is mostly about querying firmware for support. While at it I stumbled
>> >>> upon the fact that 160MHz was not completely implemented in the driv=
er
>> >>> so there is a patch for that as well.
>> >>>
>> >>> The first two patches are actually some changes to the patches that
>> >>> Rafal submitted. So this series depend on:
>> >>>
>> >>> [V3,2/2] brcmfmac: handle monitor mode marked msgbuf packets [1]
>> >>>
>> >>> These apply to the master branch of the wireless-drivers-next reposi=
tory.
>> >>>
>> >>> [1] https://patchwork.kernel.org/patch/10474799/
>> >>
>> >> I find it pointless to submit fixes for patches that weren't accepted
>> >> yet. Let's work on improving original patches while they are still
>> >> pending.
>> >
>> > I sent V4 with changes pointed our by Arend. That obsoletes all (?)
>> > monitor patches from this patchset. I believe it was cleaner to
>> > improve original patchset (not pushed yet).
>> >
>> > My suggestion is to apply patches 3/6 and 4/6 (they aren't monitor
>> > related) and drop the others.
>>
>> Well. Given that Kalle prefers applying "all-or-nothing" I will resubmit
>> the series addressing the issues you found.
>
> I wasn't aware of this, good to know, thanks!

Yes, "all-or-nothing" method is both fastest and less error prone,
that's why I prefer that. I got a bit lost with your discussion so
please check carefully that I haven't dropped anything wrong.

--=20
Kalle Valo