On 6/3/21 2:46 AM, Kalle Valo wrote: > Randy Dunlap <rdunlap@xxxxxxxxxxxxx> 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? It's all good AFAIK unless Christian wants something changed. Christian? -- ~Randy
