On Fri, 2011-11-04 at 09:11 -0700, Ben Greear wrote: > > I think maybe a single one would be sufficient, but you'd still have no > > way of knowing what is actually supported for changing. Maybe you could > > advertise an ht_mask of things that can be changed? > > That seems feasible, though it still won't help with the valid ranges > for mpdu-density, for instance. Well I still think that reducing the density is not feasible, so userspace can query the HT info about the min and the mask to see if what it can do. > How about if I add some way to query this, but leave the code loose > in that it won't fail if someone tries to set a value that isn't > supported. That way, user-space can be lazy if it wants, but > can also get the details if it cares. Yeah, that seems like it would be a good way of doing it, although I think I'd reject it if there's no such configuration possible at all. > To get this info, I'm going to have to add a new driver API, as far > as I can tell, and I only have the ability to deal with ath9k, so > that will be the only driver that reports the mask. Of course, > others could modify their drivers as they wish. I think you just have to add the mask to the wiphy struct somewhere. And the mask wouldn't be specific to ath9k since any mac80211 driver would be able to deal with it, just no non-mac80211 driver. You could just have a pointer to the mask in the wiphy struct and if NULL then it's not allowed, if non-NULL the mask indicates what can be changed. johannes -- 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
