Hi Marcel,
On Tue, May 13, 2014, Marcel Holtmann wrote:
> >>> +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.
Johan
--
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
