On 06/04/15 16:23, Kalle Valo wrote:
Hi Arend,
Arend van Spriel<ar...@broadcom.com> writes:
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.
Well, it is an integration issue. So yes, wireless-drivers-next (and
net-next) would not build for CONFIG_BCM47XX with the brcmfmac patch,
because of the missing mips patch. However, the linux-next tree will
have no build issue and consequently 4.2-rc1 will have no build issue. I
think this is acceptable although I would like to hear the opinion of
Kalle on this.
Hi Kalle,
Do you have an opinion on this? mips-next and linux-next now have the
function brcmfmac needs for CONFIG_BCM47XX so I could submit brcmfmac
patch, but that means wireless-drivers-next (and net-next) will not
build for CONFIG_BCM47XX until after the 4.2 merge window.
The answer is clear: we must not ever break the build deliberately, in
under any circumstances. Mistakes of course always happen but if we know
a patch will break the build it should not be applied.
So if patch A has a build dependency on patch B in another tree, we have
to wait for that patch B to trickle down to wireless-drivers-next before
I can commit patch A. There are other ways to speed this up if really
needed but I don't see this case is important enough for the extra
hurdle.
I haven't followed all the details so I might be missing something but I
think it would be good just to wait for 4.2-rc1, it's not that far
anyway, and go with the original Arend's plan.
Ok. I will submit the brcmfmac patch relying on the mips change to
wireless-drivers-next for 4.3 after 4.2-rc1 merge window. I will ack the
patch from Rafal in seperate email.
Regards,
Arend
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
