On 10/10/2018 01:14 PM, Johannes Berg wrote:
> Looking at all this wid_list stuff again,
>
>> + wid_list[wid_cnt].id = WID_SUCCESS_FRAME_COUNT;
>> + wid_list[wid_cnt].type = WID_INT;
>> + wid_list[wid_cnt].size = sizeof(u32);
>> + wid_list[wid_cnt].val = (s8 *)(&(dummyval));
>> + wid_cnt++;
>
> Doesn't that have endian issues?
>
>> + wid_list[wid_cnt].id = WID_RECEIVED_FRAGMENT_COUNT;
>> + wid_list[wid_cnt].type = WID_INT;
>> + wid_list[wid_cnt].size = sizeof(u32);
>> + wid_list[wid_cnt].val = (s8 *)(&(dummyval));
>> + wid_cnt++;
>
> But I'm not really sure what the pointer does, tbh.
Here the driver is configuring parameters in the device by sending a WID command for each parameters.
The val pointer points to the value of the parameter to be set, and here all parameters being set to 0 were sharing the dummyval variable.
Looking again at this, these constant parameters can be omitted from the driver and done on the device instead.
>
>> + wid_list[wid_cnt].id = WID_JOIN_REQ_EXTENDED;
>> + wid_list[wid_cnt].type = WID_STR;
>> + wid_list[wid_cnt].size = 112;
>> + wid_list[wid_cnt].val = kmalloc(wid_list[wid_cnt].size, GFP_KERNEL);
>
> I think you should declare a structure for these 112 bytes, clearly it's
> something like
>
>> + if (conn_attr->ssid) {
>> + memcpy(cur_byte, conn_attr->ssid, conn_attr->ssid_len);
>> + cur_byte[conn_attr->ssid_len] = '\0';
>> + }
>> + cur_byte += MAX_SSID_LEN;
>
> u8 ssid[32];
>
>> + *(cur_byte++) = INFRASTRUCTURE;
>
> u8 type;
>
>> +
>> + if (conn_attr->ch >= 1 && conn_attr->ch <= 14) {
>> + *(cur_byte++) = conn_attr->ch;
>> + } else {
>> + netdev_err(vif->ndev, "Channel out of range\n");
>> + *(cur_byte++) = 0xFF;
>> + }
>
> u8 channel;
>
>> + *(cur_byte++) = (bss_param->cap_info) & 0xFF;
>> + *(cur_byte++) = ((bss_param->cap_info) >> 8) & 0xFF;
>
> __le16 cap_info;
>
>> + if (conn_attr->bssid)
>> + memcpy(cur_byte, conn_attr->bssid, 6);
>> + cur_byte += 6;
>
> u8 bssid[ETH_ALEN];
>
>> + if (conn_attr->bssid)
>> + memcpy(cur_byte, conn_attr->bssid, 6);
>> + cur_byte += 6;
>
> again?
Agree. Can be changed to avoid duplication. Requires a matching change on the device.
>
>> + *(cur_byte++) = (bss_param->beacon_period) & 0xFF;
>> + *(cur_byte++) = ((bss_param->beacon_period) >> 8) & 0xFF;
>
> __le16 beacon_period;
>
>> + *(cur_byte++) = bss_param->dtim_period;
>
> u8 dtim_period;
>
> etc.
>
> Declaring it as a struct also means you don't have to do all the
> put_le16_unaligned() or whatever, but can just fill the struct properly.
>
Agree. The idea was of packing the parameters manually was to avoid struct padding issues, but I can declare the struct as packed instead
Thanks,
Adham
