net/bluetooth/: cleanups

This patch contains the following cleanups:
- remove BT_DMP/bt_dump
- remove the following unneeded EXPORT_SYMBOL's:
- hci_core.c: hci_dev_get
- hci_core.c: hci_send_cmd
- hci_event.c: hci_si_event

---

This patch was already sent on:
- 5 May 2005

 drivers/bluetooth/hci_bcsp.c      |    2 --
 drivers/bluetooth/hci_h4.c        |    5 -----
 drivers/bluetooth/hci_ldisc.c     |    2 --
 drivers/bluetooth/hci_usb.c       |    2 --
 include/net/bluetooth/bluetooth.h |    8 --------
 net/bluetooth/hci_core.c          |    2 --
 net/bluetooth/hci_event.c         |    1 -
 net/bluetooth/lib.c               |   25 -------------------------
 8 files changed, 47 deletions(-)

@@ -299,7 +299,6 @@
 	read_unlock(&hci_dev_list_lock);
 	return hdev;
 }
-EXPORT_SYMBOL(hci_dev_get);
 
 /* ---- Inquiry support ---- */
 static void inquiry_cache_flush(struct hci_dev *hdev)

@@ -1042,7 +1045,6 @@
 
 	return 0;
 }
-EXPORT_SYMBOL(hci_send_cmd);
 
 /* Get data from the previously sent command */
 void *hci_sent_cmd_data(struct hci_dev *hdev, __u16 ogf, __u16 ocf)

@@ -1040,4 +1040,3 @@
 	hci_send_to_sock(hdev, skb);
 	kfree_skb(skb);
 }
-EXPORT_SYMBOL(hci_si_event);

@@ -57,12 +57,6 @@
 #define BT_DBG(fmt, arg...)  printk(KERN_INFO "%s: " fmt "\n" , __FUNCTION__ , ## arg)
 #define BT_ERR(fmt, arg...)  printk(KERN_ERR  "%s: " fmt "\n" , __FUNCTION__ , ## arg)
 
-#ifdef HCI_DATA_DUMP
-#define BT_DMP(buf, len) bt_dump(__FUNCTION__, buf, len)
-#else
-#define BT_DMP(D...)
-#endif
-
 extern struct proc_dir_entry *proc_bt;
 
 /* Connection and socket states */

@@ -174,8 +168,6 @@
 	return n;
 }
 
-void bt_dump(char *pref, __u8 *buf, int count);
-
 int bt_err(__u16 code);
 
 #endif /* __BLUETOOTH_H */

@@ -34,31 +34,6 @@
 
 #include <net/bluetooth/bluetooth.h>
 
-void bt_dump(char *pref, __u8 *buf, int count)
-{
-	char *ptr;
-	char line[100];
-	unsigned int i;
-
-	printk(KERN_INFO "%s: dump, len %d\n", pref, count);
-
-	ptr = line;
-	*ptr = 0;
-	for (i = 0; i < count; i++) {
-		ptr += sprintf(ptr, " %2.2X", buf[i]);
-
-		if (i && !((i + 1) % 20)) {
-			printk(KERN_INFO "%s:%s\n", pref, line);
-			ptr = line;
-			*ptr = 0;
-		}
-	}
-
-	if (line[0])
-		printk(KERN_INFO "%s:%s\n", pref, line);
-}
-EXPORT_SYMBOL(bt_dump);
-
 void baswap(bdaddr_t *dst, bdaddr_t *src)
 {
 	unsigned char *d = (unsigned char *) dst;

@@ -57,8 +57,6 @@
 #ifndef CONFIG_BT_HCIUART_DEBUG
 #undef  BT_DBG
 #define BT_DBG( A... )
-#undef  BT_DMP
-#define BT_DMP( A... )
 #endif
 
 /* Initialize protocol */

@@ -125,7 +123,6 @@
 
 	BT_DBG("len %d room %d", len, room);
 	if (!len) {
-		BT_DMP(h4->rx_skb->data, h4->rx_skb->len);
 		hci_recv_frame(h4->rx_skb);
 	} else if (len > room) {
 		BT_ERR("Data length is too large");

@@ -169,8 +166,6 @@
 			case H4_W4_DATA:
 				BT_DBG("Complete data");
 
-				BT_DMP(h4->rx_skb->data, h4->rx_skb->len);
-
 				hci_recv_frame(h4->rx_skb);
 
 				h4->rx_state = H4_W4_PACKET_TYPE;

@@ -57,8 +57,6 @@
 #ifndef CONFIG_BT_HCIUART_DEBUG
 #undef  BT_DBG
 #define BT_DBG( A... )
-#undef  BT_DMP
-#define BT_DMP( A... )
 #endif
 
 static int reset = 0;

@@ -58,8 +58,6 @@
 #ifndef CONFIG_BT_HCIUART_DEBUG
 #undef  BT_DBG
 #define BT_DBG( A... )
-#undef  BT_DMP
-#define BT_DMP( A... )
 #endif
 
 static int hciextn = 1;

@@ -57,8 +57,6 @@
 #ifndef CONFIG_BT_HCIUSB_DEBUG
 #undef  BT_DBG
 #define BT_DBG(D...)
-#undef  BT_DMP
-#define BT_DMP(D...)
 #endif
 
 #ifndef CONFIG_BT_HCIUSB_ZERO_PACKET

Hi Adrian,

is this the same patch you sent me last time? I still have one of your cleanup patches in my queue. I simply was to lazy to get them back into mainline.

Regards

Marcel

No problem.

This is the same patch.

Since I didn't hear any answer from you I resended it. Now I do know that you took it.

cu
Adrian

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Hello Marcel,

I have a small app which routes back sco data received from a headset, so basically you supposed to hear yourself back in the headset. It works fine with the voice setting 0x0060, but when I switch to u-law 0x014c sound is starting to break out, if I run the program on arm using uart it works fine for both of the settings.

Using hcidump shows a regular pattern of sco receives/sends (normally like 3 packets in, 3 packets out, which is probably the result of usb buffering for incoming packets), but if I look at the output of an air-sniffer, I see that the data sent back to the headset has very
irregular time pattern (a lot of transmissions are missing), while the time pattern of incoming data from the headset is ok.
So it looks like something goes wrong after the sco data is supplied to the hci_usb. I have this problems with 2 dongles I have (BC4 and Broadcom built-in in my laptop), so does not look as a dongle problem. Any idea what might be wrong?

Well, I also have a app which does copying data received from a phone sco to a headset sco and back (2 sco channels open and app functions as a middle agent). This app is also working for arm via UART, but not on my laptop (and home pc) via usb. The question does any1 has a successful example of having 2 sco channel open (to different devices) at the same time?

Regards,
Victor.
--

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Victor,

for USB you need to set the correct alternate setting for the SCO ISOC endpoint. This should be done automaticly, but at the moment this is a static module parameter called "isoc". Look at the specification on how to calculate its value depending on the number of SCO connections and if they are 8-bit or 16-bit. The default value is 2, which means one SCO connection with 16-bit (aka voice setting 0x0060).

Regards

Marcel

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel