Hi Andrei,
>> Hiding the Bluetooth high speed support behind a module parameter is
>> not really useful. This can be enabled and disabled at runtime via
>> the management interface. This also has the advantage that his can
>
> typo here.
>
> …
the maintainer can fix that one up.
>> diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
>> index c85537c..9119898 100644
>> --- a/net/bluetooth/l2cap_sock.c
>> +++ b/net/bluetooth/l2cap_sock.c
>> @@ -445,11 +445,6 @@ static int l2cap_sock_getsockopt(struct socket *sock, int level, int optname,
>> break;
>>
>> case BT_CHANNEL_POLICY:
>> - if (!enable_hs) {
>> - err = -ENOPROTOOPT;
>> - break;
>> - }
>> -
>
> Do you think we don't need to check that HS is enabled here and below?
We can not. The socket might not be bound or the controller does not exists. So we have no way of knowing.
It should also work no matter what. The presence of an AMP controller is optional. That is why the policy is defined as BREDR_ONLY, BREDR_PREFERRED and AMP_PREFERRED. You can not force the AMP transport.
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
