[Bluez-devel] Bluetooth kernel patch for 2.6.1

[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

BCM2033 firmware loader [was Re: [Bluez-devel] Bluetooth kernel patch for 2.6.1]

[Max Krasnyansky]

On Thu, 2004-01-15 at 11:07, Marcel Holtmann wrote:
> 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. 

Marcel,

What's wrong with BlueFW ? Why did you implement BCM FW loader in the
kernel ?
I looked in the archive and the only thing I could find was that you
don't want to keep it without an explanation why.

Max

[Bluez-devel] Re: BCM2033 firmware loader

[Marcel Holtmann]

Hi Max,

> What's wrong with BlueFW ? Why did you implement BCM FW loader in the
> kernel ?
> I looked in the archive and the only thing I could find was that you
> don't want to keep it without an explanation why.

actually I never got bluefw working stable with 2.6. The usbfs interface
causes troubles which I can't explain. Maybe the problems are caused by
my hardware, but I don't know. I also want to avoid using bulk transfer
over ISOC endpoint to make OHCI happy and it seems that inside the
kernel there exists no more problems for the OHCI chips. So after I made
my experiences with the request_firmware() interface and the bfusb
driver I decided to give it a try and the bcm203x driver was born.

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: BCM2033 firmware loader

[Max Krasnyansky]

On Thu, 2004-01-15 at 12:16, Marcel Holtmann wrote:
> Hi Max,
> 
> > What's wrong with BlueFW ? Why did you implement BCM FW loader in the
> > kernel ?
> > I looked in the archive and the only thing I could find was that you
> > don't want to keep it without an explanation why.
> 
> actually I never got bluefw working stable with 2.6. The usbfs interface
> causes troubles which I can't explain. Maybe the problems are caused by
> my hardware, but I don't know. I also want to avoid using bulk transfer
> over ISOC endpoint to make OHCI happy and it seems that inside the
> kernel there exists no more problems for the OHCI chips. 
You mean Bulk over Interrupt. BlueFW doesn't send Bulk over Isoc.

> So after I made
> my experiences with the request_firmware() interface and the bfusb
> driver I decided to give it a try and the bcm203x driver was born.

I see. I have no problem with implementation in fact it's very clean and
nice. My only concern is that if it can be done from user space it
should be done in user-space thing :). I mean nobody is going to unload
this bcm203x module after fw download is complete. Yeah it's small but
it's still a waste. I'd rather fix usbfs if it's broken. Greg and
Johannes will happily accept patches ;-). 

Max

[Bluez-devel] Re: BCM2033 firmware loader

[Marcel Holtmann]

Hi Max,

> > actually I never got bluefw working stable with 2.6. The usbfs interface
> > causes troubles which I can't explain. Maybe the problems are caused by
> > my hardware, but I don't know. I also want to avoid using bulk transfer
> > over ISOC endpoint to make OHCI happy and it seems that inside the
> > kernel there exists no more problems for the OHCI chips. 
> You mean Bulk over Interrupt. BlueFW doesn't send Bulk over Isoc.

of course. I mixed it, maybe because I talked about ISOC transfer and
the HCI USB driver problem on the Linux USB mailing list ;)

> > So after I made
> > my experiences with the request_firmware() interface and the bfusb
> > driver I decided to give it a try and the bcm203x driver was born.
> 
> I see. I have no problem with implementation in fact it's very clean and
> nice. My only concern is that if it can be done from user space it
> should be done in user-space thing :). I mean nobody is going to unload
> this bcm203x module after fw download is complete. Yeah it's small but
> it's still a waste. I'd rather fix usbfs if it's broken. Greg and
> Johannes will happily accept patches ;-). 

I simply agree with you on all points. If I found enough time to look at
my usbfs problems I will try to fix them.

On the other hand it is also possible to make the firmware loading
routine of the bcm203x driver a compile time option of the hci_usb
driver. Of course this is also a waste inside the kernel, but you don't
have an extra module to load. Do you think this is a better approach?

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] Re: BCM2033 firmware loader

[Max Krasnyansky]

On Fri, 2004-01-16 at 17:19, Marcel Holtmann wrote:
> On the other hand it is also possible to make the firmware loading
> routine of the bcm203x driver a compile time option of the hci_usb
> driver. Of course this is also a waste inside the kernel, but you don't
> have an extra module to load. Do you think this is a better approach?
No no. I actually quite liked the idea of making it a separate driver.
Because it makes an unloading possible. I mean it won't be unloaded
automatically but at least you can do it manually.

I'll play with latest 2.6 and bluefw to see what's wrong with usbfs.

Thanks
Max

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