Am 27.02.2013 06:12, schrieb Dan Carpenter:
> This function is ugly because it hits against the 80 character
> limit. This patch does several things to clean it up.
>
> 1) Introduces "result" instead of inf->info.chinforesult.result[n].
> 2) Reverses the ".scanchannels & (1 << i)" so everthing can be
> pulled in one indent level.
> 3) Use "chan" instead of "channel".
> 4) Tweaks the line breaks to the call to pr_debug().
>
> Signed-off-by: Dan Carpenter <[email protected]>
>
> diff --git a/drivers/staging/wlan-ng/prism2sta.c
> b/drivers/staging/wlan-ng/prism2sta.c
> index 8d2277b..dc221f2 100644
> --- a/drivers/staging/wlan-ng/prism2sta.c
> +++ b/drivers/staging/wlan-ng/prism2sta.c
> @@ -1160,30 +1160,30 @@ static void prism2sta_inf_chinforesults(wlandevice_t
> *wlandev,
> le16_to_cpu(inf->info.chinforesult.scanchannels);
>
> for (i = 0, n = 0; i < HFA384x_CHINFORESULT_MAX; i++) {
would you mind to move the n=0 out of the for ? it has nothing (directly) todo
with
the loop. i found it confusing.
> - if (hw->channel_info.results.scanchannels & (1 << i)) {
> - int channel =
> - le16_to_cpu(inf->info.chinforesult.result[n].chid) -
> - 1;
> - hfa384x_ChInfoResultSub_t *chinforesult =
> - &hw->channel_info.results.result[channel];
> - chinforesult->chid = channel;
> - chinforesult->anl =
> - le16_to_cpu(inf->info.chinforesult.result[n].anl);
> - chinforesult->pnl =
> - le16_to_cpu(inf->info.chinforesult.result[n].pnl);
> - chinforesult->active =
> - le16_to_cpu(inf->info.chinforesult.result[n].
> - active);
> - pr_debug
> - ("chinfo: channel %d, %s level (avg/peak)=%d/%d dB, pcf %d\n",
> - channel + 1,
> - chinforesult->
> - active & HFA384x_CHINFORESULT_BSSACTIVE ? "signal"
> - : "noise", chinforesult->anl, chinforesult->pnl,
> - chinforesult->
> - active & HFA384x_CHINFORESULT_PCFACTIVE ? 1 : 0);
> - n++;
> - }
> + hfa384x_ChInfoResultSub_t *result;
> + hfa384x_ChInfoResultSub_t *chinforesult;
> + int chan;
> +
> + if (!(hw->channel_info.results.scanchannels & (1 << i)))
> + continue;
> +
> + result = &inf->info.chinforesult.result[n];
> + chan = le16_to_cpu(result->chid) - 1;
> +
> + chinforesult = &hw->channel_info.results.result[chan];
> + chinforesult->chid = chan;
> + chinforesult->anl = le16_to_cpu(result->anl);
> + chinforesult->pnl = le16_to_cpu(result->pnl);
> + chinforesult->active = le16_to_cpu(result->active);
> +
> + pr_debug("chinfo: channel %d, %s level (avg/peak)=%d/%d dB, pcf
> %d\n",
> + chan + 1,
> + (chinforesult->active & HFA384x_CHINFORESULT_BSSACTIVE)
> + ? "signal" : "noise",
> + chinforesult->anl, chinforesult->pnl,
> + (chinforesult->active & HFA384x_CHINFORESULT_PCFACTIVE)
> + ? 1 : 0);
> + n++;
> }
> atomic_set(&hw->channel_info.done, 2);
This is much better readable !
but i am missing the point why where are two counters.
i is simple. it is used to check the bitfield
hw->channel_info.results.scanchannels
n is increased only the when a bit is set. So it would be more easy to simply
count the bits and run the loop about that number.
But i can also imagine that the bitfield act as "enable" and the author actualy
should read &inf->info.chinforesult.result[i];
perhaps i am missing the point, could someone tell me were i am wrong ?
re,
wh
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
_______________________________________________
devel mailing list
[email protected]
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
