On Tue, Aug 4, 2009 at 8:37 AM, Pat Erley<pat-lkml@xxxxxxxxx> wrote: > Richard Farina wrote: >> Johannes Berg wrote: >>> Then, finally, I'd add a new channel type, NL80211_CHANNEL_TYPE_5MHZ. >>> Document it to imply that HT is being turned off, of course. Now this >>> bit should be really simple. >>> >>> >> But why? There is no reason mcs rates can't be used on 5/10 Mhz channels >> as far as I know. Bad enough these channels are running at half and >> quarter rates, if you can use mcs why not? >> >> Just my 0.02 >> >> thanks, >> Rick Farina > > My thought on this topic is: design everything so these COULD be supported, > but wait until someone tests/implements this functionality with a driver > and needs support for them. If I understood Johannes' description of things > correctly, if it was found that a driver could do mcs rates in other channel > widths, it'd be as simple as adding the values to the bitfields and that > driver testing/implementing that functionality. > > What I guess it's come around to is: > > 1. Change the way the current functionality is implemented > 2. Add additional values as it's added. > > What I believe johannes was saying is, during the implementation of 5/10mhz > channels, disable ht/mcs modes up front, until someone shows/implements it. You won't get support from vendors if the feature used is non-standard though. Just keep that in mind. In fact I'm not sure its a good idea to simply enable this off hand. We may want to consider a way to annotate unsupported features if they are in fact very easy to implement. So far we have simply opted to not support non-standard features. I don't think we should strive away from that as I think it has helped keep our code base clean and simple. 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
