On 9-1-2017 9:58, Johannes Berg wrote: > On Sat, 2017-01-07 at 13:58 +0100, Rafał Miłecki wrote: > >>> I indeed prefer to talk about the driver instead of we. Indeed it >>> is true due to the orig_flags behavior although that only seems to >>> involve regulatory code. Could it be that brcmfmac undo that >>> through the notifier? >> >> I guess you could touch orig_flags, but I don't know if it's >> preferred way. This is probably question to Johannes & cfg80211 guys. > > Right now - before the OF patch - there can't really be any orig_flags > with DISABLED since the driver doesn't set flags to DISABLED before > registering, does it? While registering, flags are copied to orig_flags > so the driver can register with flags like DFS or NO_IR already enabled > - say the firmware requires that - and they will never be overwritten > by cfg80211. Actually, in brcmfmac we do set channels to DISABLED before registering. I was blissfully unaware of the orig_flags when I added the channel setup in our probe sequence. > Arguably, what the driver does today - before OF - isn't incorrect > either, since it simply doesn't care about anything it registered with > at all. Given the statement above I think brcmfmac is incorrect. > However, with the OF, I argued (succesfully it seems :P) that the > sensible thing to do was to register with the DISABLED flag and thereby > "permanently" disable the channels that OF didn't think were usable, > but in this case now the driver has to adhere to the cfg80211 logic of > preserving orig_flags forever. By adhere you mean we should not enable channes for which orig_flags indicate DISABLED? Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
