On 28 May 2015 at 23:24, Arend van Spriel <arend@xxxxxxxxxxxx> wrote: > On 05/28/15 14:34, Rafał Miłecki wrote: >> >> On 28 May 2015 at 13:54, Arend van Spriel<arend@xxxxxxxxxxxx> wrote: >>> >>> On 05/28/15 13:37, Rafał Miłecki wrote: >>>> >>>> >>>> As we plan to add support for platform NVRAM we should store direct >>>> data pointer without the extra struct firmware layer. This will allow >>>> us to support other sources with the only requirement being u8 buffer. >>>> >>>> Signed-off-by: Rafał Miłecki<zajec5@xxxxxxxxx> >>>> Signed-off-by: Hante Meuleman<meuleman@xxxxxxxxxxxx> >>>> Signed-off-by: Arend van Spriel<arend@xxxxxxxxxxxx> >>>> --- >>>> Tested on router with BCM43602-s using >>>> /lib/firmware/brcm/brcmfmac43602-pcie.txt >>>> >>>> I've written this patch from scratch, it's inspired by the dropped: >>>> [PATCH 6/6] brcmfmac: Add support for host platform NVRAM loading. >>> >>> >>> >>> Hi Rafał, >>> >>> So what is your goal here. The inspirational patch was dropped so it can >>> be >>> resubmitted when the mips change it relies on has made its way upstream. >>> So >>> I have to rebase the patch over here and your patch will just give me >>> conflicts during that rebase. So can we please wait or do you need this >>> change right now. >> >> >> The dropped patch will require rebasing/rewriting anyway. There were >> few changes to firmware.c already, I've few more planned, you'll have >> to drop some code form your patch (parts that will go into MIPS tree) >> and probably apply few changes as requested in comments. > > > I already did that and submitted the mips part to Ralf. I am sorry to say > this but what annoys me is that since then you started submitting patches > that seem to be taken from the dropped patch. So I have a problem seeing the > bright side. If Ralf takes the mips part it ends up in linux-next and we can > submit the brcmfmac part. This is truly the first patch based on your dropped one. All other 5 patches were addressing problems I noticed by myself. One of them fixed the same issue you /silently/ did in the dropped one, but I wasn't even aware of that until I started rebasing your patch. We simply noticed the same problem and fixed it on our owns. So I think this patch is the only one that could annoy you, but *honestly* my intention was exactly the opposite. As already said, I just wanted to do possible cleanup early and let you maintain 50% of your original patch instead the whole one. I really don't want to have you annoyed because the need of rebasing your patch. What you said about Ralf's tree and linux-next isn't exactly true. I do believe Kalle won't merge linux-next into wireless-driver-next, so we have to wait for 4.2-rc1, then for Dave merging Linus's tree, then Kalle merging Dave's tree. We really shouldn't stop development for weeks because of having some patch prepared for later submitting. I think the only think you can do to make your life easier is to submit cleanup part of your prepared patch. This is exactly what I tried to do for you. -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
