On Mon, Aug 2, 2010 at 2:17 AM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: > On 2010-08-02 11:10 AM, Luis R. Rodriguez wrote: >> On Mon, Aug 2, 2010 at 1:59 AM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: >>> On 2010-08-02 7:37 AM, Luis R. Rodriguez wrote: >>>> I'm not, the point I was trying to make is that solving this for >>>> legacy and that for 802.11n this needs more thought and work. >>> I need this for 802.11n as well, and I believe the API is good enough >>> for that. >> >> Sure. >> >>>>> as long as the API is flexible >>>>> enough i think it can be added later as 802.11n devices are going to accept >>>>> antenna configuration. >>>> >>>> If you want really flexible stuff without addressing serious >>>> considerations before introducing a new kernel API then use debugfs. >>> I'd like to see this in nl80211. Is there any specific concern left that >>> I haven't addressed already? If so, please point me at it... >> >> The code that deals with not accepting changes unless we're not >> associated, and that also caches the old real hw config vs the >> modified one. > This is not really an API issue, this is more of an implementation > aspect. I think it's up to the driver to reject changes that it cannot > handle at the moment. Huh,why not deal with this on cfg80211 and/or mac80211? > For legacy, changing settings is fine in any state (even with assoc). Sure. > For 802.11n, changes that affect the chainmask should be rejected while > the interface is up. That way we don't run into weird cached config vs > hw config issues, and also keep a sane state for the HT capabilities. Sure, I just did not see any code for this in these patches. My point about the hw config vs fake/mod'd is if we'd expose the mod'd config changes to userspace or if we'd keep them internal to cfg80211. How would this be dealt with? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
