Hi Stefan, stefan@xxxxxxxxxxxxxxxxxx wrote on Wed, 19 Oct 2022 10:06:05 +0200: > Hello. > > On 19.10.22 00:03, Miquel Raynal wrote: > > Hi Alexander, > > > > aahringo@xxxxxxxxxx wrote on Tue, 18 Oct 2022 16:54:13 -0400: > > > >> Hi, > >> > >> On Tue, Oct 18, 2022 at 2:35 PM Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > >>> > >>> We now have a fine grained filtering information so let's ensure proper > >>> filtering in scan mode, which means that only beacons are processed. > >>> >> > >> Is this a fixup? Can you resend the whole series please? > > > > Hmm no? Unless I understood things the wrong way, Stefan applied > > patches 1 to 7 of my v4, and asked me to make a change on the 8th > > patch. > > > > This is v5 just for patch 8/8 of the previous series, I just changed > > a debug string actually... > > > > There was a conflict when he applied it but I believe this is because > > wpan-next did not contain one of the fixes which made it to Linus' tree > > a month ago. So in my branch I still have this fix prior to this patch, > > because otherwise there will be a conflict when merging v6.1-rc1 (which > > I believe was not done yet). > > You believe correctly. :-) In my workflow I normally do not merge in changes from net-next until after my latest pull-request was pulled in. I do this to avoid extra merge commits. > > In case I see a merge conflict in my testing before sending the pull request I add merge guidance to the pull. Which is my plan this time around as well. Do you mean I should drop the fix from my branch and give you a patch which applies on the current wpan-next instead? Thanks, Miquèl
