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 also don't think it makes much sense to pause any development because of having some out-of-tree patch queued for later submitting. And after all, hey, look at the bright side! :) With this patch you'll have to maintain smaller amount of out-of-tree(-for-now) code :) So my goals are: 1) Have all required cleanups pushed mainline early. 2) Make it easier to main out-of-tree changes. The personal reason behind that is to add OpenWrt support for BCM43602 as early as possible. Having clean backports + tiny NVRAM patch make it much easier to do now, maintain and update in the future. -- 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
