2011/5/12 Johannes Berg <johannes@xxxxxxxxxxxxxxxx>: > On Wed, 2011-05-11 at 23:39 +0200, Björn Smedman wrote: >> 2011/5/11 Johannes Berg <johannes@xxxxxxxxxxxxxxxx>: >> > On Wed, 2011-05-11 at 17:58 +0200, Björn Smedman wrote: >> >> I'm very interested in having multiple AP vifs with different beacon >> >> intervals. If we're going to just fail anyway in this case can't we do >> >> that from the drivers instead? I would also prefer that from an >> >> aesthetic point of view, instead of having broken logic in the drivers >> >> "protected" by extra verification in cfg80211. >> > >> > We can't fail from the drivers, they don't have a failure path. >> >> Wouldn't it be best to add a failure path? Based a quick look it seems >> a little complicated but not unmanageable... Or what do you think? > > It's not overly complicated, but I don't like it anyway, that just opens > the door to the drivers failing all kinds of things and to userspace > that'll look random. > >> Is there anything else where the driver may not support a certain >> combination of bss configurations? From the top of my head I can think >> of mac address. That should fail as well depending on HW capability, >> right? That seems to be another code path but the same problem (no >> failure path). > > That has a failure path, and recently I posted a patch to advertise the > interface type combinations. I don't think MAC addresses impose any sort > of restriction. I think at least some rt2x00 hw may not be able to handle all combinations of multi-vif MAC addresses. If I understand correctly ath9k will happily configure the hardware to ack all BSSIDs if multi-vif MAC addresses are poorly chosen. I don't know if that's a reason to fail but it wouldn't be good, right? Another case where cross-vif constraints are difficult to handle is BSS_CHANGED_ERP_SLOT / BSS_CHANGED_ERP_PREAMBLE. Again, I'm not sure failing is the right way to handle this but at least ath9k seems incapable of having separate slot times / preambles for separate vifs... > Bottom line is this: We currently don't have a driver that handles this > correctly. Therefore, the patch is absolutely correct. If somebody > enhances drivers, they're free to also enhance the checking code, and > (hopefully) include some advertising of what is possible. Currently, > however, the best assumption is that it's not possible, and we should > encode that assumption somewhere in the userspace API. Sounds reasonable. Thanks for explaining. /Björn -- 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
