Hi Johan,
>>>>> +static int get_conn_info(struct sock *sk, struct hci_dev *hdev, void *data,
>>>>> + u16 len)
>>>>> +{
>>>>> + struct mgmt_cp_get_conn_info *cp = data;
>>>>> + struct mgmt_rp_get_conn_info rp;
>>>>> + struct hci_conn *conn;
>>>>> + unsigned long conn_info_age;
>>>>> + int err = 0;
>>>>> +
>>>>> + BT_DBG("%s", hdev->name);
>>>>> +
>>>>> + memset(&rp, 0, sizeof(rp));
>>>>> + bacpy(&rp.addr.bdaddr, &cp->addr.bdaddr);
>>>>> + rp.addr.type = cp->addr.type;
>>>>
>>>> Do we really want to just keep zeroed out values and not set the
>>>> values to invalid. What are we doing for other commands that
>>>> require the same return parameters set to match up with the remote
>>>> address.
>>>
>>> Actually there's no other command which returns address *and* some
>>> parameters so this will be first one. So in case of failure should we
>>> put proper 'invalid' values into response parameter and not just
>>> leaving them set to zero? There is always error code which means
>>> request failed and returned parameters are invalid anyway. And in case
>>> of success response we overwrite zeroes with proper values of course.
>>
>> good question. Johan, what do you think?
>
> I'm fine with the "zeroes in case of failure" approach. It's also
> consistent with the "sender sets to zero and receiver ignores" approach
> that's present in various protocol specs for reserved or invalid parts
> of PDUs. That said, I'm not sure if there is a simple example to be
> taken for reference from the HCI spec.
okay, then we go with the zero. However that means that mgmt-api.txt needs to mention that these fields are invalid in case of error response.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
