On Mon, Aug 2, 2010 at 2:32 AM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: > On 2010-08-02 11:23 AM, Luis R. Rodriguez wrote: >> 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? > Right now, the drivers calculate this. We could make a helper function > in cfg80211 at some point, but we're talking about really small chunks > of code. > >>> 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? > Right now, cfg80211 doesn't know enough to handle this stuff on its own, > so let's handle it in the driver completely on the first iteration. The > patches do not need any changes for this right now. I'd prefer that code to be written rather then let this be defined as API now and let drivers deal with this differently. But that's me, I'm not the maintainer, I just will not deal with bug reports dealing with this and I'll assign them to you guys if this gets through. Still think its crap and should just go through debugfs until all the code mentioned does exist. 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
