Hi Marcel,
Marcel Holtmann <marcel <at> holtmann.org> writes:
> > > we can do this and actually calling "hcitool cc" does this already, but
> > > it waits indeed for a timeout of the HCI_Disconnect.
> >
> > Could you give a few more details on this one, please? What I want to do is
> > what Pieter suggested: have the Hardware Error event trigger an unexpected
> > link loss on all active connections.
>
> if you wanna do this, then this should be done directly in the Bluetooth
> core module in the kernel. Look at hci_event.c and add the handling for
> the hardware error event to trigger the appropriate actions.
I know that it has to be done in hci_event.c; what I was trying to figure out
was what the necessary actions are. As far as I've been able to tell the
function hci_conn_hash_flush in hci_conn.c seems to do most of the work. Is that
it or is there something else to do? Should we tasklet_kill the RX and TX tasks?
A somewhat unrelated question, but I could not help noticing this: in
hci_conn.c, in function hci_conn_del there is this:
if (conn->type == SCO_LINK) {
struct hci_conn *acl = conn->link;
if (acl) {
acl->link = NULL;
hci_conn_put(acl);
}
} else {
struct hci_conn *sco = conn->link;
if (sco)
sco->link = NULL;
/* Unacked frames */
hdev->acl_cnt += conn->sent;
}
I don't claim to have a good understanding of this code, but it seems that on
the true branch ACL is handled and on the false branch, SCO is handled. So
shouldn't that be:
if (conn->type != SCO_LINK)
Thanks for your help,
Catalin
-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Catalin,
> > > Could you give a few more details on this one, please? What I want to do is
> > > what Pieter suggested: have the Hardware Error event trigger an unexpected
> > > link loss on all active connections.
> >
> > if you wanna do this, then this should be done directly in the Bluetooth
> > core module in the kernel. Look at hci_event.c and add the handling for
> > the hardware error event to trigger the appropriate actions.
>
> I know that it has to be done in hci_event.c; what I was trying to figure out
> was what the necessary actions are. As far as I've been able to tell the
> function hci_conn_hash_flush in hci_conn.c seems to do most of the work. Is that
> it or is there something else to do? Should we tasklet_kill the RX and TX tasks?
I am not 100% sure, but the right actions seem to me:
disable RX task
disable TX task
lock device
flush connection hash
unlock device
call flush() function of the driver
disable cmd task
drop rx queue
drop cmd queue
drop raw queue
drop last sent command
enable RX task
enable TX task
enable cmd task
It is somekind of tricky to get this fully correct and I don't have any
device to really test it. However send in a patch when you got it done.
> A somewhat unrelated question, but I could not help noticing this: in
> hci_conn.c, in function hci_conn_del there is this:
>
> if (conn->type == SCO_LINK) {
> struct hci_conn *acl = conn->link;
> if (acl) {
> acl->link = NULL;
> hci_conn_put(acl);
> }
> } else {
> struct hci_conn *sco = conn->link;
> if (sco)
> sco->link = NULL;
>
> /* Unacked frames */
> hdev->acl_cnt += conn->sent;
> }
>
> I don't claim to have a good understanding of this code, but it seems that on
> the true branch ACL is handled and on the false branch, SCO is handled. So
> shouldn't that be:
>
> if (conn->type != SCO_LINK)
You are wrong here. We check for conn->link and that is the associated
SCO or ACL link.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Catalin,
> > > I'm not that familiar with the architecture of BlueZ but with the
> > > experiences for our own stack I can tell you this is not trivial. The main
> > > problem here is that the Bluetooth Stack is not stateless. One possible
> > > solution is to feed the reset done event to the higher layers (l2cap). But
> > > than L2cap must be modified to correctly shut down all connections. It
> > > would be easier if the HCI layer tracks the state of all ACL and SCO
> > > connections (Marcel ??). Than a reset done event can be handled like a
> > > unexpected link loss on all active connections and the higher layers do
> > > not need any modifications (hopefully).
> >
> > we can do this and actually calling "hcitool cc" does this already, but
> > it waits indeed for a timeout of the HCI_Disconnect.
>
> Could you give a few more details on this one, please? What I want to do is what
> Pieter suggested: have the Hardware Error event trigger an unexpected link loss
> on all active connections.
if you wanna do this, then this should be done directly in the Bluetooth
core module in the kernel. Look at hci_event.c and add the handling for
the hardware error event to trigger the appropriate actions.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel