Message ID | 20181023.202921.1185045750138652543.davem@davemloft.net |
---|---|
State | Accepted, archived |
Delegated to: | David Miller |
Headers | show |
Series | [GIT] Networking | expand |
On Wed, Oct 24, 2018 at 4:30 AM David Miller <davem@davemloft.net> wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git Hmm. Tentatively pulled, but there's something wrong with the Kconfig rules. Doing "make allmodconfig" (not even the build itself, just the config phase), I get WARNING: unmet direct dependencies detected for QCOM_QMI_HELPERS Depends on [n]: ARCH_QCOM && NET [=y] Selected by [m]: - ATH10K_SNOC [=m] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && ATH10K [=m] && (ARCH_QCOM || COMPILE_TEST [=y]) because I'm obviously not building on ARCH_QCOM. I suspect that QCOM_QMI_HELPERS needs to have depends on (ARCH_QCOM || COMPILE_TEST) && NET or similar. I'll see if this builds for me at all despite the Kconfig warning. Linus
On Wed, Oct 24, 2018 at 7:01 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > Hmm. Tentatively pulled, but there's something wrong with the Kconfig rules. Confirmed. I did a978a5b8d83f ("net/kconfig: Make QCOM_QMI_HELPERS available when COMPILE_TEST") to fix the breakage. Why wasn't this noticed in testing? Linus
+ linux-wireless, ath10k, niklas, jeff, andy, david Linus Torvalds <torvalds@linux-foundation.org> writes: > On Wed, Oct 24, 2018 at 4:30 AM David Miller <davem@davemloft.net> wrote: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git > > Hmm. Tentatively pulled, but there's something wrong with the Kconfig rules. > > Doing "make allmodconfig" (not even the build itself, just the config > phase), I get > > WARNING: unmet direct dependencies detected for QCOM_QMI_HELPERS > Depends on [n]: ARCH_QCOM && NET [=y] > Selected by [m]: > - ATH10K_SNOC [=m] && NETDEVICES [=y] && WLAN [=y] && > WLAN_VENDOR_ATH [=y] && ATH10K [=m] && (ARCH_QCOM || COMPILE_TEST > [=y]) > > because I'm obviously not building on ARCH_QCOM. > > I suspect that QCOM_QMI_HELPERS needs to have > > depends on (ARCH_QCOM || COMPILE_TEST) && NET > > or similar. I'll see if this builds for me at all despite the Kconfig warning. I had missed this warning, sorry about that. Jeff reported the same problem while I was on vacation and according to Niklas[1] it should be fixed by this commit in linux-next: ccfb464cd106 ("soc: qcom: Allow COMPILE_TEST of qcom SoC Kconfigs") I'm hoping you will get the commit during this merge window but not sure about that and via which tree it would come. Adding Andy and David who hopefully know more. [1] http://lists.infradead.org/pipermail/ath10k/2018-October/012330.html
Linus Torvalds <torvalds@linux-foundation.org> writes: > On Wed, Oct 24, 2018 at 7:01 AM Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> >> Hmm. Tentatively pulled, but there's something wrong with the Kconfig rules. > > Confirmed. BTW, our emails crossed and more info in the other email[1]. > I did a978a5b8d83f ("net/kconfig: Make QCOM_QMI_HELPERS available when > COMPILE_TEST") to fix the breakage. Thanks, though I don't see it yet as I guess you haven't pushed it yet. Do note that it _might_ conflict the other commit which I suspect is in also coming to you: ccfb464cd106 ("soc: qcom: Allow COMPILE_TEST of qcom SoC Kconfigs") > Why wasn't this noticed in testing? Mostly bad timing due to my vacation. I did do allmodconfig build but not sure why I missed the warning, also the kbuild bot didn't report anything. Jeff did report[2] it last week but I was on vacation at the time and just came back yesterday and didn't have time to react to it yet. Really sorry for the mess. [1] https://lkml.kernel.org/r/87pnvzu7i6.fsf@codeaurora.org [2] http://lists.infradead.org/pipermail/ath10k/2018-October/012330.html
Kalle Valo <kvalo@codeaurora.org> writes: > Linus Torvalds <torvalds@linux-foundation.org> writes: > >> On Wed, Oct 24, 2018 at 7:01 AM Linus Torvalds >> <torvalds@linux-foundation.org> wrote: >>> >>> Hmm. Tentatively pulled, but there's something wrong with the Kconfig rules. >> >> Confirmed. > > BTW, our emails crossed and more info in the other email[1]. > >> I did a978a5b8d83f ("net/kconfig: Make QCOM_QMI_HELPERS available when >> COMPILE_TEST") to fix the breakage. > > Thanks, though I don't see it yet as I guess you haven't pushed it yet. > Do note that it _might_ conflict the other commit which I suspect is in > also coming to you: > > ccfb464cd106 ("soc: qcom: Allow COMPILE_TEST of qcom SoC Kconfigs") git.kernel.org is alive again for me so I can now check both commits. It seems that Niklas' commit[1] is more finegrained than what Linus did[2]. I guess either of the commits should be reverted when Niklas' commit goes to Linus tree, or what's the best course of action? [1] https://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git/commit/?h=for-next&id=ccfb464cd106890cfa51070f75921a273e2852e5 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a978a5b8d83f795e107a2ff759b28643739be70e
Sorry for spam, I am resending in cleartext because the previous missed the lists. Thanks Google for resetting my config when you 'upgraded'. On Wed, 24 Oct 2018 at 09:05, Kalle Valo <kvalo@qca.qualcomm.com> wrote: > > Kalle Valo <kvalo@codeaurora.org> writes: > > > Linus Torvalds <torvalds@linux-foundation.org> writes: > > > >> On Wed, Oct 24, 2018 at 7:01 AM Linus Torvalds > >> <torvalds@linux-foundation.org> wrote: > >>> > >>> Hmm. Tentatively pulled, but there's something wrong with the Kconfig rules. > >> > >> Confirmed. > > > > BTW, our emails crossed and more info in the other email[1]. > > > >> I did a978a5b8d83f ("net/kconfig: Make QCOM_QMI_HELPERS available when > >> COMPILE_TEST") to fix the breakage. > > > > Thanks, though I don't see it yet as I guess you haven't pushed it yet. > > Do note that it _might_ conflict the other commit which I suspect is in > > also coming to you: > > > > ccfb464cd106 ("soc: qcom: Allow COMPILE_TEST of qcom SoC Kconfigs") > > git.kernel.org is alive again for me so I can now check both commits. It > seems that Niklas' commit[1] is more finegrained than what Linus did[2]. > I guess either of the commits should be reverted when Niklas' commit > goes to Linus tree, or what's the best course of action? Yes this will conflict with Niklas's patch which is part of the 4.20 pull requests. I would prefer that we revert Linus's and take Niklas's unless there is a compelling argument to have it fixed before -rc1. That said, if you didn't, the merge conflicts would be minor and easily handled. Regards, Andy Gross
On Wed, Oct 24, 2018 at 2:24 PM Andy Gross <andy.gross@linaro.org> wrote: > > Yes this will conflict with Niklas's patch which is part of the 4.20 > pull requests. I would prefer that we revert Linus's and take Niklas's > unless there is a compelling argument to have it fixed before -rc1. I have no objection to just reverting my patch when I get the real fix. I just don't want my tree to have warnings that I see, and that may hide new warnings coming in when I do my next pull request.. Linus