t btusb_setup_intel_newgen(struct hci_dev
> *hdev)
> */
> btintel_load_ddc_config(hdev, ddcname);
>
> - /* Read the Intel supported features and if new exception formats
> -* supported, need to load the additional DDC config to enable.
> -*/
> - btintel_read_debug_features(hdev, );
> -
> - /* Set DDC mask for available debug features */
> - btintel_set_debug_features(hdev, );
> -
> /* Read the Intel version information after loading the FW */
> err = btintel_read_version_tlv(hdev, );
> if (err)
> --
> 2.31.1.295.g9ea45b61b8-goog
>
--
Luiz Augusto von Dentz
dev
> *hdev)
> */
> btintel_load_ddc_config(hdev, ddcname);
>
> - /* Read the Intel supported features and if new exception formats
> -* supported, need to load the additional DDC config to enable.
> - */
> - btintel_read_debug_features(hdev, );
> -
> - /* Set DDC mask for available debug features */
> - btintel_set_debug_features(hdev, );
> -
> /* Read the Intel version information after loading the FW */
> err = btintel_read_version_tlv(hdev, );
> if (err)
> --
> 2.31.1.295.g9ea45b61b8-goog
>
--
Luiz Augusto von Dentz
Hi Emil,
On Sun, Mar 21, 2021 at 4:23 PM Emil Lenngren wrote:
>
> Hi,
>
> Den mån 22 mars 2021 kl 00:01 skrev Luiz Augusto von Dentz
> :
> > Or we do something like
> > https://lore.kernel.org/linux-bluetooth/20201024002251.1389267-1-luiz.de...@gmail.com/,
> &g
thing like
https://lore.kernel.org/linux-bluetooth/20201024002251.1389267-1-luiz.de...@gmail.com/,
that said the reason we didn't applied my patches was that the
controller would be the one generating invalid data, but it seems you
are reproducing with vhci controller which is only used for emulating
a controller and requires root privileges so it is unlikely these
conditions would happens with hardware itself, in the other hand as
there seems to be more and more reports using vhci to emulate broken
events it perhaps more productive to introduce proper checks for all
events so we don't have to deal with more reports like this in the
future.
> Others =
>
> Please let me know if there is any confuses.
> Best wishes!
--
Luiz Augusto von Dentz
t2.648 seconds
Add Ext Advertising - Success (Shortened name) Timed out1.993 seconds
Add Ext Advertising - Success (Short name) Timed out2.004 seconds
These tests expect the Set Extended Scan Response Data to be send but
it is not and then it times out, the problem seems to be that
get_adv_instance_scan_rsp_len does check for things like include
local-name on instances other than 0, also we probably need to include
some logic to check if the instance is really scannable to begin with.
--
Luiz Augusto von Dentz
test, also tester supports the concept of 'not run'
which we can probably use for experimental commands.
> Thanks,
> Daniel
>
> On Thu, Oct 29, 2020 at 5:04 PM Luiz Augusto von Dentz
> wrote:
> >
> > Hi Daniel,
> >
> > On Thu, Oct 29, 2020 at 3:25 PM Dani
Hi Daniel,
On Thu, Oct 29, 2020 at 3:25 PM Daniel Winkler wrote:
>
> Hi Luiz,
>
> Thank you for the feedback regarding mgmt-tester. I intended to use
> the tool, but found that it had a very high rate of test failure even
> before I started adding new tests. If you have a strong preference for
>
nd tx power from mgmt cmds
> > Bluetooth: Query LE tx power on startup
> > Bluetooth: Change MGMT security info CMD to be more generic
> >
> > include/net/bluetooth/hci.h | 7 +
> > include/net/bluetooth/hci_core.h | 12 +-
> > include/net/bluetooth/mgmt.h | 49 +++-
> > net/bluetooth/hci_core.c | 47 +++-
> > net/bluetooth/hci_event.c| 19 ++
> > net/bluetooth/hci_request.c | 29 ++-
> > net/bluetooth/mgmt.c | 424 +--
> > 7 files changed, 542 insertions(+), 45 deletions(-)
> >
> > --
> > 2.28.0.709.gb0816b6eb0-goog
> >
--
Luiz Augusto von Dentz
r_smp,
> > > by moving it from the SMP registration to the BR/EDR controller init
> > > section. hci_debugfs_create_bredr is only called when HCI_SETUP and
> > > HCI_CONFIG is not set.
> > >
> > > Signed-off-by: Claire Chang
> Reviewed-by: Alain Michau
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 3dede8ebf46338473143a1e792cc2cacc244f1f2
Gitweb:
https://git.kernel.org/tip/3dede8ebf46338473143a1e792cc2cacc244f1f2
Author:Luiz Augusto von Dentz
AuthorDate:Thu, 06 Aug 2020 11:17:12 -07
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: a0a91211dd0ac6f24393a2917a258de5aeedb842
Gitweb:
https://git.kernel.org/tip/a0a91211dd0ac6f24393a2917a258de5aeedb842
Author:Luiz Augusto von Dentz
AuthorDate:Thu, 06 Aug 2020 11:17:14 -07
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 122414e2d2cba74dc154263cabca9560ff8011ac
Gitweb:
https://git.kernel.org/tip/122414e2d2cba74dc154263cabca9560ff8011ac
Author:Luiz Augusto von Dentz
AuthorDate:Thu, 06 Aug 2020 11:17:11 -07
o_filter_duration),
> };
> struct mgmt_rp_read_def_system_config *rp = (void *)params;
>
> @@ -138,6 +140,8 @@ int set_def_system_config(struct sock *sk, struct hci_dev
> *hdev, void *data,
> case 0x0019:
> case 0x001a:
> case 0x001b:
> + case 0x001d:
> + case 0x001e:
> if (len != sizeof(u16)) {
> bt_dev_warn(hdev, "invalid length %d, exp %zu
> for type %d",
> len, sizeof(u16), type);
> @@ -251,6 +255,12 @@ int set_def_system_config(struct sock *sk, struct
> hci_dev *hdev, void *data,
> hdev->def_le_autoconnect_timeout =
>
> msecs_to_jiffies(TLV_GET_LE16(buffer));
> break;
> + case 0x0001d:
> + hdev->advmon_allowlist_duration =
> TLV_GET_LE16(buffer);
> + break;
> + case 0x0001e:
> + hdev->advmon_no_filter_duration =
> TLV_GET_LE16(buffer);
> + break;
> default:
> bt_dev_warn(hdev, "unsupported parameter %u", type);
> break;
> --
> 2.28.0.681.g6f77f65b4e-goog
>
--
Luiz Augusto von Dentz
Hi Archie,
On Tue, Sep 22, 2020 at 12:37 AM Archie Pusaka wrote:
>
> Hi Luiz,
>
> On Tue, 22 Sep 2020 at 01:13, Luiz Augusto von Dentz
> wrote:
> >
> > Hi Archie,
> >
> > On Mon, Sep 21, 2020 at 1:31 AM Archie Pusaka wrote:
> > >
> > > F
Hi Archie,
On Tue, Sep 22, 2020 at 12:48 AM Archie Pusaka wrote:
>
> Hi Luiz,
>
> On Tue, 22 Sep 2020 at 01:15, Luiz Augusto von Dentz
> wrote:
> >
> > Hi Archie,
> >
> >
> > On Mon, Sep 21, 2020 at 12:56 AM Archie Pusaka wrote:
> > >
ck_link_mode(conn->hcon)) {
> + (!hci_conn_check_link_mode(conn->hcon) ||
> + !l2cap_check_enc_key_size(conn->hcon))) {
I wonder if we couldn't incorporate the check of key size into
hci_conn_check_link_mode, like I said in the first patch checking the
enc key size should not be specific to L2CAP.
> conn->disc_reason = HCI_ERROR_AUTH_FAILURE;
> result = L2CAP_CR_SEC_BLOCK;
> goto response;
> --
> 2.28.0.681.g6f77f65b4e-goog
>
--
Luiz Augusto von Dentz
hcon->enc_key_size >= min_key_size);
While this looks fine to me, it looks like this should be placed
elsewhere since it takes an hci_conn and it is not L2CAP specific.
> }
>
> static void l2cap_do_start(struct l2cap_chan *chan)
> --
> 2.28.0.681.g6f77f65b4e-goog
>
--
Luiz Augusto von Dentz
idr_for_each(>adv_monitors_idr, _adv_monitor,
> hdev);
> --
> 2.28.0.618.gf4bc123cb7-goog
This looks like a kernel patch so you shouldn't be prefixing it with
BlueZ as it might confuse CI.
--
Luiz Augusto von Dentz
On Wed, Aug 19, 2020 at 11:23 AM Pali Rohár wrote:
>
> On Wednesday 19 August 2020 11:21:00 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> >
> > On Wed, Aug 19, 2020 at 7:37 AM Pali Rohár wrote:
> > >
> > > On Friday 14 August 2020 12:56:05 Luiz
Hi Pali,
On Wed, Aug 19, 2020 at 7:37 AM Pali Rohár wrote:
>
> On Friday 14 August 2020 12:56:05 Luiz Augusto von Dentz wrote:
> > Hi Joseph,
> >
> > On Thu, Aug 13, 2020 at 1:42 AM Joseph Hwang wrote:
> > >
> > > It is desirable to expose the wideba
n;
Id use sco_mtu to so the following check actually does what it intended to do:
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/bluetooth/sco.c#n283
Right now it seems we are using the buffer length as MTU but I think
we should actually use the packet length if it is lower than the
buffer length, actually it doesn't seems SCO packets can be fragmented
so the buffer length must always be big enough to carry a full packet
so I assume setting the packet length as conn->mtu will always be
correct.
>
> __u16 block_len;
> __u16 block_mtu;
> --
> 2.28.0.236.gb10cc79966-goog
>
--
Luiz Augusto von Dentz
; int level, int optname,
> err = -EFAULT;
> break;
>
> + case BT_SCO_PKT_LEN:
> + if (put_user(sco_pi(sk)->pkt_len, (u32 __user *)optval))
> + err = -EFAULT;
> + break;
Couldn't we expose this via BT_SNDMTU/BT_RCVMTU?
> default:
> err = -ENOPROTOOPT;
> break;
> --
> 2.28.0.236.gb10cc79966-goog
>
--
Luiz Augusto von Dentz
ut I am willing to provide
> any logs, do tests and try patches.
>
> I am running fedora 32 on the affected system which has built-in intel
> wireless/bluetooth card,
>
> PCI (wifi) part:
> 47:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)
>
> USB (bluetooth) parrt:
> Bus 011 Device 004: ID 8087:0029 Intel Corp.
>
> My .config attached (custom built kernel)
>
> Best regards,
> Maxim Levitsky
>
--
Luiz Augusto von Dentz
_hdr *)skb->data;
> >> >>> + handle = hci_handle(__le16_to_cpu(hdr->handle));
> >> >>> +
> >> >>> + if (handle == oldest_handle) {
> >> >>> + __skb_unlink(skb, >pending_acl_q);
> >> >>> + kfree_skb(skb);
> >> >>> + }
> >> >>> + }
> >> >>> +
> >> >>> + if (!skb_queue_empty(>pending_acl_q))
> >> >>> + queue_delayed_work(hdev->workqueue,
> >> >>> >remove_pending_acl,
> >> >>> +PENDING_ACL_TIMEOUT);
> >> >>> +}
> >> >>> +
> >> >>
> >> >> So I am wondering if we make this too complicated. Since generally
> >> >> speaking we can only have a single HCI connect complete anyway at a
> >> >> time. No matter if the controller serializes it for us or we do it for
> >> >> the controller. So hci_conn_add could just process the queue for
> >> >> packets with its handle and then flush it. And it can flush it no
> >> >> matter what since whatever other packets are in the queue, they can not
> >> >> be valid.
> >> >>
> >> >> That said, we wouldn’t even need to check the packet handles at all. We
> >> >> just needed to flag them as already out-of-order queued once and hand
> >> >> them back into the rx_q at the top. Then the would be processed as
> >> >> usual. Already ooo packets would cause the same error as before if it
> >> >> is for a non-existing handle and others would end up being processed.
> >> >>
> >> >> For me this means we just need another queue to park the packets until
> >> >> hci_conn_add gets called. I might have missed something, but I am
> >> >> looking for the least invasive option for this and least code
> >> >> duplication.
> >> >
> >> > I'm not aware of the fact that we can only have a single HCI connect
> >> > complete event at any time. Is this also true even if two / more
> >> > peripherals connect at the same time?
> >> > I was under the impression that if we have device A and B both are
> >> > connecting to us at the same time, we might receive the packets in
> >> > this order:
> >> > (1) ACL A
> >> > (2) ACL B
> >> > (3) HCI conn evt B
> >> > (4) HCI conn evt A
> >> > Hence the queue and the handle check.
> >>
> >> my reading from the LL state machine is that once the first LL_Connect_Req
> >> is processes, the controller moves out of the advertising state. So no
> >> other LL_Connect_Req can be processed. So that means that connection
> >> attempts are serialized.
> >>
> >> Now if you run AE and multiple instances, that might be different, but
> >> then again, these instances are also offset in time and so I don’t see how
> >> we can get more than one HCI_Connection_Complete event at a time (and with
> >> that a leading ACL packet).
> >>
> >> Regards
> >>
> >> Marcel
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "ChromeOS Bluetooth Upstreaming" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to chromeos-bluetooth-upstreaming+unsubscr...@chromium.org.
> >> To post to this group, send email to
> >> chromeos-bluetooth-upstream...@chromium.org.
> >> To view this discussion on the web visit
> >> https://groups.google.com/a/chromium.org/d/msgid/chromeos-bluetooth-upstreaming/7BBB55E0-FBD9-40C0-80D9-D5E7FC9F80D2%40holtmann.org.
--
Luiz Augusto von Dentz
result = L2CAP_CR_SEC_BLOCK;
> >>> + goto response;
> >>> + }
> >>> +
> >>> + l2cap_add_pending_encrypt_conn(conn, req, ident, rsp_code,
> >>> +amp_id);
> >>> + result = L2CAP_CR_PEND;
> >>> goto response;
> >>> }
> >>
> >> So I am actually wondering if the approach is not better to send back a
> >> pending to the connect request like we do for everything else. And then
> >> proceed with getting our remote L2CAP information. If these come back in
> >> encrypted, then we can assume that we actually had encryption enabled and
> >> proceed with a L2CAP connect response saying that all is fine.
> >
> > I wonder if we should resolve this by having different queues in
> > hci_recv_frame (e.g. hdev->evt_rx), that way we can dequeue the HCI
> > events before ACL so we first update the HCI states before start
> > processing the L2CAP data, thoughts? Something like this:
> >
> > https://gist.github.com/Vudentz/464fb0065a73e5c99bdb66cd2c5a1a2d
>
> No. We need to keep things serialized. We actually have to reject unencrypted
> packets.
>
> So whatever we do needs to be behind a quirk and an explicit opt-in.
While I agree we are just working around the real issue, Id guess
processing the event before ACL would work (I haven't tested it yet)
much better than leaving this up to the L2CAP layer since that
requires a timer in order for us to e.g. accept/reject the connection
request, also since this problem is known to affect other events as
well (e.g. data for ATT coming before Connection Complete) I guess
using the time the kernel takes to schedule the rx_work as the window
where we would assume the packets arrived 'at same time' so we can
resolve the conflicts between endpoints. On top of this we could
perhaps consider using a delayed work for rx_work so the driver can
actually tune up what is the time window (perhaps for USB that should
be the polling interval) where we would consider events and data that
have arrived at same time.
Or are you saying that the conflict resolution I proposed would
actually break things? I could picture any event that if it were
processed before the data at such a short time window would, note here
I'm talking about miliseconds not seconds so it is not that this will
be doing much reordering and if we go with delayed work it should be
relatively simple to add a Kconfig option(build-time)/module(runtime)
parameter to btusb to configure the interface were we would do such
reordering which the default could be 0 in which case we can just keep
queuing everything on rx_q.
> Regards
>
> Marcel
>
--
Luiz Augusto von Dentz
m != cpu_to_le16(L2CAP_PSM_SDP) &&
> > !hci_conn_check_link_mode(conn->hcon)) {
> > - conn->disc_reason = HCI_ERROR_AUTH_FAILURE;
> > - result = L2CAP_CR_SEC_BLOCK;
> > + if (!queue_if_fail) {
> > + conn->disc_reason = HCI_ERROR_AUTH_FAILURE;
> > + result = L2CAP_CR_SEC_BLOCK;
> > + goto response;
> > + }
> > +
> > + l2cap_add_pending_encrypt_conn(conn, req, ident, rsp_code,
> > +amp_id);
> > + result = L2CAP_CR_PEND;
> > goto response;
> > }
>
> So I am actually wondering if the approach is not better to send back a
> pending to the connect request like we do for everything else. And then
> proceed with getting our remote L2CAP information. If these come back in
> encrypted, then we can assume that we actually had encryption enabled and
> proceed with a L2CAP connect response saying that all is fine.
I wonder if we should resolve this by having different queues in
hci_recv_frame (e.g. hdev->evt_rx), that way we can dequeue the HCI
events before ACL so we first update the HCI states before start
processing the L2CAP data, thoughts? Something like this:
https://gist.github.com/Vudentz/464fb0065a73e5c99bdb66cd2c5a1a2d
> That also means no queuing of packets is required.
>
> Regards
>
> Marcel
>
--
Luiz Augusto von Dentz
be in charge to decide if the link
should be disconnected or not.
> > Please share your thoughts on this.
>
> I am look into this. Just bare with me for a bit to verify the call chain.
>
> Regards
>
> Marcel
>
--
Luiz Augusto von Dentz
hdr->evt);
> return false;
> --
> 2.7.4
It appears we need this also for enabling vendor_diag with intel controllers:
[399314.236288] hci_cmd_status_evt:3138: hci0 opcode 0xfc43
[399314.236291] Bluetooth: hci0: last event is not cmd complete (0x0f)
[399314.236359] Bluetooth: hci0: Changing Intel diagnostic mode failed (-16)
--
Luiz Augusto von Dentz
hdr->evt);
> return false;
> --
> 2.7.4
It appears we need this also for enabling vendor_diag with intel controllers:
[399314.236288] hci_cmd_status_evt:3138: hci0 opcode 0xfc43
[399314.236291] Bluetooth: hci0: last event is not cmd complete (0x0f)
[399314.236359] Bluetooth: hci0: Changing Intel diagnostic mode failed (-16)
--
Luiz Augusto von Dentz
Hi Alex,
On Mon, Jan 22, 2018 at 5:33 PM, Alexander Aring <alex.ar...@gmail.com> wrote:
> Hi,
>
> 2018-01-22 8:00 GMT-05:00 Luiz Augusto von Dentz <luiz.de...@gmail.com>:
>> Hi Alex,
>>
> ...
>>>
>>> or is there a special bluetooth API call
Hi Alex,
On Mon, Jan 22, 2018 at 5:33 PM, Alexander Aring wrote:
> Hi,
>
> 2018-01-22 8:00 GMT-05:00 Luiz Augusto von Dentz :
>> Hi Alex,
>>
> ...
>>>
>>> or is there a special bluetooth API call needed, like the current case
>>> with debugfs.
Hi Alex,
On Wed, Jan 17, 2018 at 3:37 PM, Alexander Aring <alex.ar...@gmail.com> wrote:
> Hi,
>
> 2018-01-17 7:15 GMT-05:00 Luiz Augusto von Dentz <luiz.de...@gmail.com>:
>> Hi,
>>
>> On Wed, Jan 17, 2018 at 1:47 AM, Guo Yi <yi2010@samsung.com> wr
Hi Alex,
On Wed, Jan 17, 2018 at 3:37 PM, Alexander Aring wrote:
> Hi,
>
> 2018-01-17 7:15 GMT-05:00 Luiz Augusto von Dentz :
>> Hi,
>>
>> On Wed, Jan 17, 2018 at 1:47 AM, Guo Yi wrote:
>>> This patch fix the bluetooth 6lowpan disconnect fail bug.
>>&g
onn_hash_lookup_le(hdev, addr, *addr_type);
> + hcon = hci_conn_hash_lookup_le(hdev, addr, lookup_type);
> hci_dev_unlock(hdev);
>
> if (!hcon)
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Luiz Augusto von Dentz
i_conn_hash_lookup_le(hdev, addr, lookup_type);
> hci_dev_unlock(hdev);
>
> if (!hcon)
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Luiz Augusto von Dentz
e, so I could be missing
> something, but I got the feeling that this part would make more sense if
> it was at process_adv_report(), there's even the check for a pending
> connection, so no need to redo that here.
Actually I would use the AD only in case the device is marked for
auto-connect or there is a connection pending, so the parameters are
only used for the connection alone and are not persisted.
> Apart from this, the series looks good.
>
>
>> mgmt_event(MGMT_EV_DEVICE_FOUND, hdev, ev, ev_size, NULL);
>> }
>>
>> --
>> 2.12.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Cheers,
> --
> Vinicius
--
Luiz Augusto von Dentz
se if
> it was at process_adv_report(), there's even the check for a pending
> connection, so no need to redo that here.
Actually I would use the AD only in case the device is marked for
auto-connect or there is a connection pending, so the parameters are
only used for the connection alone and are not persisted.
> Apart from this, the series looks good.
>
>
>> mgmt_event(MGMT_EV_DEVICE_FOUND, hdev, ev, ev_size, NULL);
>> }
>>
>> --
>> 2.12.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Cheers,
> --
> Vinicius
--
Luiz Augusto von Dentz
n->conn, skb);
> -
> - if (!skb)
> - return;
> -
> - lowpan_cb(skb)->status = 0;
> + BT_DBG("chan %p resume", chan);
> }
>
> static long chan_get_sndtimeo_cb(struct l2cap_chan *chan)
> --
> 2.11.0
It should be possible to queue the packets on l2cap_chan_send, Im not
sure why we have this suspend logic in the first place so perhaps
Jukka can shed some light here.
--
Luiz Augusto von Dentz
return;
> -
> - lowpan_cb(skb)->status = 0;
> + BT_DBG("chan %p resume", chan);
> }
>
> static long chan_get_sndtimeo_cb(struct l2cap_chan *chan)
> --
> 2.11.0
It should be possible to queue the packets on l2cap_chan_send, Im not
sure why we have this suspend logic in the first place so perhaps
Jukka can shed some light here.
--
Luiz Augusto von Dentz
> *peer_addr_type = peer->chan->dst_type;
> lowpan_cb(skb)->chan = peer->chan;
>
> --
> 2.11.0
Reviewed-by: Luiz Augusto von Dentz <luiz.von.de...@intel.com>
--
Luiz Augusto von Dentz
ct
> net_device *netdev,
> }
>
> daddr = peer->lladdr;
> - peer_addr = >chan->dst;
> + *peer_addr = peer->chan->dst;
> *peer_addr_type = peer->chan->dst_type;
> lowpan_cb(skb)->chan = peer->chan;
>
> --
> 2.11.0
Reviewed-by: Luiz Augusto von Dentz
--
Luiz Augusto von Dentz
l_hci_conn_list_purge(btpf);
> + rtl_profile_list_purge(btpf);
> +
> + btpf_close_socket(btpf);
> +
> + kfre
; + destroy_workqueue(btpf->workq);
> +
> + del_timer_sync(>a2dp_timer);
> + del_timer_sync(>pan_timer);
> +
> + rtl_hci_conn_list_purge(btpf);
> + rtl_profile_list_purge(btpf);
> +
> + btpf_close_socket(btpf);
> +
> +
truct socket *sock, struct
> msghdr
>
> skb_free_datagram(sk, skb);
>
> - if (msg->msg_flags & MSG_TRUNC)
> + if (flags & MSG_TRUNC)
> copied = skblen;
>
> return err ? : copied;
> --
I believe similar patches already went to bluetooth-next so it should
be in the way if not already merged.
--
Luiz Augusto von Dentz
gram(sk, skb);
>
> - if (msg->msg_flags & MSG_TRUNC)
> + if (flags & MSG_TRUNC)
> copied = skblen;
>
> return err ? : copied;
> --
I believe similar patches already went to bluetooth-next so it should
be in the way if not already merged.
--
Luiz Augusto von Dentz
t just doesn't work without any errors displayed in dmesg.
We might need some logs, bluetoothd logs and btmon trace, to start
with, I don't recall any recent changes in HID just in HoG (Bluetooth
LE/Smart) which uses uHID.
--
Luiz Augusto von Dentz
--
To unsubscribe from this list: send the
without any errors displayed in dmesg.
We might need some logs, bluetoothd logs and btmon trace, to start
with, I don't recall any recent changes in HID just in HoG (Bluetooth
LE/Smart) which uses uHID.
--
Luiz Augusto von Dentz
--
To unsubscribe from this list: send the line unsubscribe linux
cp.role = 0x01; /* Remain slave */
> --
> 1.8.2.1
I guess the real issue is the possibility of creating a scatternet if
you have more than one connection, I will send a patch for scatternet
shortly but that does not guarantee the remote device wont reject it.
--
Luiz
*/
--
1.8.2.1
I guess the real issue is the possibility of creating a scatternet if
you have more than one connection, I will send a patch for scatternet
shortly but that does not guarantee the remote device wont reject it.
--
Luiz Augusto von Dentz
--
To unsubscribe from this list: send
TIMEOUT, so perhaps if we can
identify which command is more likely to timeout.
We could perhaps auto reset if a command timeout if there is really no
other way to recover.
--
Luiz Augusto von Dentz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
if there is really no
other way to recover.
--
Luiz Augusto von Dentz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
51 matches
Mail list logo
