From: Kalle Valo <kvalo@codeaurora.org>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: Christian Lamparter <chunkeey@gmail.com>,
linux-kernel@vger.kernel.org, kernel test robot <lkp@intel.com>,
linux-wireless@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v3] wireless: carl9170: fix LEDS build errors & warnings
Date: Thu, 03 Jun 2021 12:46:00 +0300 [thread overview]
Message-ID: <87czt31dt3.fsf@codeaurora.org> (raw)
In-Reply-To: <c49c07d5-1d6e-5b99-30b4-bc8f48b0fde3@infradead.org> (Randy Dunlap's message of "Sun, 30 May 2021 07:32:07 -0700")
Randy Dunlap <rdunlap@infradead.org> writes:
> On 5/30/21 2:31 AM, Christian Lamparter wrote:
>> On 30/05/2021 05:11, Randy Dunlap wrote:
>>> kernel test robot reports over 200 build errors and warnings
>>> that are due to this Kconfig problem when CARL9170=m,
>>> MAC80211=y, and LEDS_CLASS=m.
>>>
>>> WARNING: unmet direct dependencies detected for MAC80211_LEDS
>>> Depends on [n]: NET [=y] && WIRELESS [=y] && MAC80211 [=y] &&
>>> (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=MAC80211 [=y])
>>> Selected by [m]:
>>> - CARL9170_LEDS [=y] && NETDEVICES [=y] && WLAN [=y] &&
>>> WLAN_VENDOR_ATH [=y] && CARL9170 [=m]
>>>
>>> CARL9170_LEDS selects MAC80211_LEDS even though its kconfig
>>> dependencies are not met. This happens because 'select' does not follow
>>> any Kconfig dependency chains.
>>>
>>> Fix this by making CARL9170_LEDS depend on MAC80211_LEDS, where
>>> the latter supplies any needed dependencies on LEDS_CLASS.
>>
>> Ok, this is not what I was expecting... I though you would just
>> add a "depends on / imply MAC80211_LEDS" on your v2. (this was
>> based on the assumption of what mac80211, ath9k/_htc and mt76
>> solutions of the same problem looked like).
>
> Do you want the user choice/prompt removed, like MT76 is?
>
>> But since (I assuming here) this patch passed the build-bots
>> testing with flying colors in the different config permutations.
>
> It hasn't passed any build-bots testing that I know of.
> I did 8 combinations of kconfigs (well, 2 of them were invalid),
> but they all passed my own build testing.
So is this ok to take now? Or will there be v4?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2021-06-03 9:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-30 3:11 [PATCH v3] wireless: carl9170: fix LEDS build errors & warnings Randy Dunlap
2021-05-30 9:07 ` Arnd Bergmann
2021-05-30 9:31 ` Christian Lamparter
2021-05-30 14:32 ` Randy Dunlap
2021-06-03 9:46 ` Kalle Valo [this message]
2021-06-03 15:20 ` Randy Dunlap
2021-06-03 18:10 ` Christian Lamparter
2021-06-12 10:38 ` Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87czt31dt3.fsf@codeaurora.org \
--to=kvalo@codeaurora.org \
--cc=arnd@arndb.de \
--cc=chunkeey@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lkp@intel.com \
--cc=rdunlap@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.