[Bluez-devel] Bluetooth kernel patch for 2.6.1

[Bluez-devel] Bluetooth kernel patch for 2.6.1

[Marcel Holtmann]

Hi Folks,

the first Bluetooth kernel patch for 2.6.1 is now available [1] and it
is only a resync with the previous 2.6.0-mh2 patch. Here is the full
changelog:

  o Convert interrupt handlers to use irqreturn_t
  o Support for Broadcom Blutonium
  o Improve blacklist handling
  o Add missing maintainer entries for the Bluetooth subsystem
  o Add CAPI message transport protocol support
  o Update the Kconfig entry for the BlueFRITZ! USB driver
  o Add module aliases for the Bluetooth protocols
  o Support for AVM BlueFRITZ! USB
  o Remove USB zero packet option
  o Support inquiry results with RSSI
  o Update HCI security filter
  o Add support for an old ALPS module
  o Add support for the Digianswer USB devices
  o Always use two ISOC URB's
  o Disable credit based flow control by default

Regards

Marcel

[1] http://www.holtmann.org/linux/kernel/patch-2.6.1-mh1.gz




-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] Bluetooth kernel patch for 2.6.1

[Marcel Holtmann]

Hi Folks,

the second Bluetooth kernel patch for 2.6.1 is now available [1] and it
includes some additional stuff. Here is the changelog:

  o Set disconnect timer for incoming ACL links
  o Use R2 for default value of pscan_rep_mode
  o Fix CMTP reference counting

Regards

Marcel

[1] http://www.holtmann.org/linux/kernel/patch-2.6.1-mh2.gz




-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] Bluetooth kernel patch for 2.6.1

[Marcel Holtmann]

Hi Folks,

the third Bluetooth kernel patch for 2.6.1 is now available [1]. It
fixes the inquiry after boot problem and the RFCOMM reference counting
bug. Here is the changelog:

  o Change maintainer role of the Bluetooth subsystem
  o Start inquiry if cache is empty
  o Fix reference counting for incoming connections

Regards

Marcel

[1] http://www.holtmann.org/linux/kernel/patch-2.6.1-mh3.gz




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth kernel patch for 2.6.1

[Max Krasnyansky]

Some more comments about the patch.

- BCM203x loader
Should mention (at the top) that it's based on the user-space BCM loader
Copyright (C) such and such (eg me ;-))

- RFCOMM disable CFC by default
Comment should mention that it's a forward port of 2.4 patch by maxk.

- This
> static inline void hci_conn_put(struct hci_conn *conn) 
>  {
>  	if (atomic_dec_and_test(&conn->refcnt)) {
> -		if (conn->type == SCO_LINK)
> +		if (conn->type == ACL_LINK) {
> +			unsigned long timeo = (conn->out) ?
> +				HCI_DISCONN_TIMEOUT : HCI_DISCONN_TIMEOUT * 2;
> +			hci_conn_set_timer(conn, timeo);
> +		} else
>  			hci_conn_set_timer(conn, HZ / 100);
> -		else if (conn->out)
> -			hci_conn_set_timer(conn, HCI_DISCONN_TIMEOUT);
>  	}
>  }

will kill _incoming_ connection when last local socket is closed. I used
to have HCI_CONNIDLE_TIMEOUT for that. But I got rid of it because I
think it's wrong. We should not kill incoming ACL connection. It should
be killed by the initiator.

Max

Re: [Bluez-devel] Bluetooth kernel patch for 2.6.1

[Marcel Holtmann]

Hi Max,

> - BCM203x loader
> Should mention (at the top) that it's based on the user-space BCM loader
> Copyright (C) such and such (eg me ;-))

I am going to add this. From an USB dump of the Windows driver I
remember that it is doing some more stuff before it finishes the
firmware loading. Do you have the complete specs from Broadcom for these
devices?

> - RFCOMM disable CFC by default
> Comment should mention that it's a forward port of 2.4 patch by maxk.

I am sorry about that. Simply forgot to add the statement while porting
all left over stuff from 2.4 and 2.6. I keep an eye on it in the future.

> - This
> > static inline void hci_conn_put(struct hci_conn *conn) 
> >  {
> >  	if (atomic_dec_and_test(&conn->refcnt)) {
> > -		if (conn->type == SCO_LINK)
> > +		if (conn->type == ACL_LINK) {
> > +			unsigned long timeo = (conn->out) ?
> > +				HCI_DISCONN_TIMEOUT : HCI_DISCONN_TIMEOUT * 2;
> > +			hci_conn_set_timer(conn, timeo);
> > +		} else
> >  			hci_conn_set_timer(conn, HZ / 100);
> > -		else if (conn->out)
> > -			hci_conn_set_timer(conn, HCI_DISCONN_TIMEOUT);
> >  	}
> >  }
> 
> will kill _incoming_ connection when last local socket is closed. I used
> to have HCI_CONNIDLE_TIMEOUT for that. But I got rid of it because I
> think it's wrong. We should not kill incoming ACL connection. It should
> be killed by the initiator.

You are absolutly right and I can only agree with you, but the reality
is different. The problem is that some devices don't care about their
ACL links (for example the Apple Bluetooth mouse) and the Bluetooth
specification says nothing about the ownership of an ACL link. There is
no rule who must terminate an ACL link if it is no longer used.

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth kernel patch for 2.6.1

[Max Krasnyansky]

On Thu, 2004-01-15 at 12:30, Marcel Holtmann wrote:
> Hi Max,
> 
> > - BCM203x loader
> > Should mention (at the top) that it's based on the user-space BCM loader
> > Copyright (C) such and such (eg me ;-))
> 
> I am going to add this. From an USB dump of the Windows driver I
> remember that it is doing some more stuff before it finishes the
> firmware loading. Do you have the complete specs from Broadcom for these
> devices?
No. I have several email with Broadcomm engineer who explained how
protocol works. That's pretty much it. He didn't mention any additional
stuff.

> > - This
> > > static inline void hci_conn_put(struct hci_conn *conn) 
> > >  {
> > >  	if (atomic_dec_and_test(&conn->refcnt)) {
> > > -		if (conn->type == SCO_LINK)
> > > +		if (conn->type == ACL_LINK) {
> > > +			unsigned long timeo = (conn->out) ?
> > > +				HCI_DISCONN_TIMEOUT : HCI_DISCONN_TIMEOUT * 2;
> > > +			hci_conn_set_timer(conn, timeo);
> > > +		} else
> > >  			hci_conn_set_timer(conn, HZ / 100);
> > > -		else if (conn->out)
> > > -			hci_conn_set_timer(conn, HCI_DISCONN_TIMEOUT);
> > >  	}
> > >  }
> > 
> > will kill _incoming_ connection when last local socket is closed. I used
> > to have HCI_CONNIDLE_TIMEOUT for that. But I got rid of it because I
> > think it's wrong. We should not kill incoming ACL connection. It should
> > be killed by the initiator.
> 
> You are absolutly right and I can only agree with you, but the reality
> is different. The problem is that some devices don't care about their
> ACL links (for example the Apple Bluetooth mouse) and the Bluetooth
> specification says nothing about the ownership of an ACL link. There is
> no rule who must terminate an ACL link if it is no longer used.
I'm trying to remember scenario where it was a problem (ie us killing
incoming connection) but it simply vanished from my memory :).
But I still think it's not right, even though spec does not say who must
close the connection (are you sure it doesn't btw ?). That Bluetooth
mouse must have its reasons for keeping connection and if you kill it
most likely they just reconnect immediately.

Max 

Re: [Bluez-devel] Bluetooth kernel patch for 2.6.1

[Marcel Holtmann]

Hi Max,

> No. I have several email with Broadcomm engineer who explained how
> protocol works. That's pretty much it. He didn't mention any additional
> stuff.

I have a nice USB dump from the Windows driver. Of course it uses an
older firmware and mini driver, but it also issues another status
command before selecting the memory. I decided not to include it,
because I can't decode the extra information and it makes the driver
more complex. Do you have a contact for me, so we can talk about it. I
am also interested in a Bluetooth 1.2 firmware if it exists.

> I'm trying to remember scenario where it was a problem (ie us killing
> incoming connection) but it simply vanished from my memory :).

I talked a little bit with Steven and Chris from CSR about it (look at
the archive) and of course there can be a problem with some link manager
implementation if both sides issue HCI_Disconnect at the same time. This
is why I choose the double time if we disconnect an incoming connection
to be safe for BlueZ <-> BlueZ connections.

> But I still think it's not right, even though spec does not say who must
> close the connection (are you sure it doesn't btw ?). That Bluetooth
> mouse must have its reasons for keeping connection and if you kill it
> most likely they just reconnect immediately.

I came around with this on 21 Dec and I thought about it for over 3
weeks before I finally decided to include this patch. I am not happy
with it, but doing nothing and keep the ACL link makes me even more sad.
The Apple mouse with its Broadcom HID stack is even more worse than I
can think about it. At http://www.holtmann.org/linux/bluetooth/hid.html
you find some of my notes about Bluetooth HID devices. And the mouse
never disconnects the ACL link. I checked this and it stays forever :(

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Bluetooth kernel patch for 2.6.1

[Max Krasnyansky]

On Fri, 2004-01-16 at 17:08, Marcel Holtmann wrote:
> Hi Max,
> 
> > No. I have several email with Broadcomm engineer who explained how
> > protocol works. That's pretty much it. He didn't mention any additional
> > stuff.
> 
> I have a nice USB dump from the Windows driver. Of course it uses an
> older firmware and mini driver, but it also issues another status
> command before selecting the memory. I decided not to include it,
> because I can't decode the extra information and it makes the driver
> more complex. 
I don't think it's needed. May be for the old firmware. Or maybe
something Windows specific.

> Do you have a contact for me, so we can talk about it. I
> am also interested in a Bluetooth 1.2 firmware if it exists.
I'm actually subscribed to Broadcomm release notifications. 
So I'll get and email as soon as the release something. I don't think
that they have 1.2 support yet. Anyway this subscription and stuff is
kind of proprietary. One of the reasons I got it is because I'm a
Qualcommer :).

> > I'm trying to remember scenario where it was a problem (ie us killing
> > incoming connection) but it simply vanished from my memory :).
> 
> I talked a little bit with Steven and Chris from CSR about it (look at
> the archive) and of course there can be a problem with some link manager
> implementation if both sides issue HCI_Disconnect at the same time. This
> is why I choose the double time if we disconnect an incoming connection
> to be safe for BlueZ <-> BlueZ connections.
> 
> > But I still think it's not right, even though spec does not say who must
> > close the connection (are you sure it doesn't btw ?). That Bluetooth
> > mouse must have its reasons for keeping connection and if you kill it
> > most likely they just reconnect immediately.
> 
> I came around with this on 21 Dec and I thought about it for over 3
> weeks before I finally decided to include this patch. I am not happy
> with it, but doing nothing and keep the ACL link makes me even more sad.
> The Apple mouse with its Broadcom HID stack is even more worse than I
> can think about it. At http://www.holtmann.org/linux/bluetooth/hid.html
> you find some of my notes about Bluetooth HID devices. And the mouse
> never disconnects the ACL link. I checked this and it stays forever :(

I see. Well I guess it's ok as long as it doesn't brake anything.

Max

Re: [Bluez-devel] Bluetooth kernel patch for 2.6.1

[Marcel Holtmann]

Hi Max,

> > Do you have a contact for me, so we can talk about it. I
> > am also interested in a Bluetooth 1.2 firmware if it exists.
> I'm actually subscribed to Broadcomm release notifications. 
> So I'll get and email as soon as the release something. I don't think
> that they have 1.2 support yet. Anyway this subscription and stuff is
> kind of proprietary. One of the reasons I got it is because I'm a
> Qualcommer :).

I tried to contact the guys from Broadcom, but they never answered. This
makes me really unhappy.

> > I came around with this on 21 Dec and I thought about it for over 3
> > weeks before I finally decided to include this patch. I am not happy
> > with it, but doing nothing and keep the ACL link makes me even more sad.
> > The Apple mouse with its Broadcom HID stack is even more worse than I
> > can think about it. At http://www.holtmann.org/linux/bluetooth/hid.html
> > you find some of my notes about Bluetooth HID devices. And the mouse
> > never disconnects the ACL link. I checked this and it stays forever :(
> 
> I see. Well I guess it's ok as long as it doesn't brake anything.

Actually I must say I hope so ;)

The current way of waiting 4 seconds before we kill an incoming and
unused ACL link should be really long enough and in the most cases the
remote device already disconnected it before the timer kicks in. However
I haven't seen any problems in the last three weeks while I tested this
patch on my machines.

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel