Hi, On 10:51 Tue 30 Apr, Marcel Holtmann wrote: > Hi Vinicius, > > >> The choice between LE and BR/EDR should be made on the destination > >> address type instead of the destination CID. This is particularly > >> important when in the future more than one CID will be allowed for LE. > >> > >> Signed-off-by: Johan Hedberg <johan.hedberg@xxxxxxxxx> > >> --- > >> net/bluetooth/l2cap_core.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c > >> index d5e4404..95d46cd 100644 > >> --- a/net/bluetooth/l2cap_core.c > >> +++ b/net/bluetooth/l2cap_core.c > >> @@ -1792,7 +1792,7 @@ int l2cap_chan_connect(struct l2cap_chan *chan, __le16 psm, u16 cid, > >> > >> auth_type = l2cap_get_auth_type(chan); > >> > >> - if (chan->dcid == L2CAP_CID_ATT) > >> + if (bdaddr_type_is_le(dst_type)) > > > > Wouldn't this break applications that rely on the CID for making a LE > > connection? > > which application are these. They are all from the time where enable_le=0 was the default. We introduced the BD_ADDR address type before we enabled LE by default. I was thinking "old" BlueZ releases, 4.99 would have this issue, 4.101 is fine. Fair enough. That argument about the address type being added before LE being enabled by default convinced me. > > Regards > > Marcel > Cheers, -- Vinicius -- 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
