> > + chan =
> > ieee80211_frequency_to_channel(center_freq);
> > +
> > + if (first_chan == 0) {
> > + /* first subband */
> > + first_chan = chan;
> > + count = 1;
> > + } else if (first_chan + count == chan) {
> > + /* continue the subband.
> > + * TODO: this is really only useful
> > for 2.4,
> > + * need to add spacing considerations for other
> > + * bands as well (the definition of a
> > subband
> > + * in the 802.11 spec. is a bit
> > vague).
> > + */
> > + count++;
>
> I agree this is very vague - anyone have a good idea who to ask?
>
> As it is now, I'm not sure it's correct at all, even in the version we have today,
> since different operating classes could have different requirements.
> Especially since we support 5/10 MHz now, I suspect even
> ieee80211_frequency_to_channel() really should be taught about operating
> classes in some form?
>
> > + /* Get the number of enabled channels for spectrum management
> */
> > + n_channels = ieee80211_get_num_enabled_channels(local-
> >hw.wiphy);
>
> I would prefer you did this with an upper bound rather than the number of
> enabled channels - we don't need a good estimate, worst case we'll allocate
> a few bytes too many, but if we get it completely wrong e.g.
> because the channel flags are being changed, then we could overrun the SKB
> allocation, I think?
>
> It'd also be faster to iterate only the bands and add up n_channels rather
> than checking each channel's enabled bit.
>
Sure. I'll modify the utility function as the same logic that you suggested is used in a couple of other places in the code.
Ilan.
��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
