Hi Lukasz, On Fri, Jan 23, 2015, Lukasz Rymanowski wrote: > If user space is trying to do LE pair but LE has not been enabled then > MGMT_STATUS_REJECT will be returned. > > Same result code will be returned also in case of BREDR pairing if BREDR > is not enabled. > > Having separate error code for that scenario might be useful for > debugging at least. > > Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@xxxxxxxxx> > --- > net/bluetooth/mgmt.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c > index 41e3005..e03e63c 100644 > --- a/net/bluetooth/mgmt.c > +++ b/net/bluetooth/mgmt.c > @@ -3246,6 +3246,8 @@ static int pair_device(struct sock *sk, struct hci_dev *hdev, void *data, > > if (PTR_ERR(conn) == -EBUSY) > status = MGMT_STATUS_BUSY; > + else if (PTR_ERR(conn) == -EOPNOTSUPP) > + status = MGMT_STATUS_REJECTED; > else > status = MGMT_STATUS_CONNECT_FAILED; Good catch, but I'd like to keep this consistent with our handling of LE support elsewhere. Particularly, I'd like to follow the same semantics as the mgmt_le_support() helper function, meaning if the HW doesn't support LE we get NOT_SUPPORTED whereas if it does support LE but it's simply not enabled we get REJECTED. You could e.g. use EOPNOTSUPP for non-LE HW and ECONNREFUSED for LE not enabled (feel free to propose a better errno to mgmt status mapping). 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
