From: "Gustavo F. Padovan" <gustavo@padovan.org>
To: Suraj Sumangala <suraj@atheros.com>
Cc: Suraj Sumangala <Suraj.Sumangala@Atheros.com>,
"linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>,
"marcel@holtmann.org" <marcel@holtmann.org>,
Luis Rodriguez <Luis.Rodriguez@Atheros.com>,
Jothikumar Mothilal <Jothikumar.Mothilal@Atheros.com>
Subject: Re: [PATCH v4] Add support for the Atheros AR300x Bluetooth Chip
Date: Thu, 22 Apr 2010 05:59:22 -0300 [thread overview]
Message-ID: <20100422085922.GG22959@vigoh> (raw)
In-Reply-To: <4BCFF28C.8000606@atheros.com>
Hi Suraj,
* Suraj Sumangala <suraj@atheros.com> [2010-04-22 12:24:04 +0530]:
>
> Hi Gustavo,
>
> Gustavo F. Padovan wrote:
> >* suraj <suraj@atheros.com> [2010-04-21 15:52:17 +0530]:
> >
> >>This implements the Atheros Bluetooth serial protocol to
> >>support the AR300x Bluetooth chipsets.
> >>The serial protocol implements enhanced power management
> >>features for the AR300x chipsets.
> >>
> >>Reviewed-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> >>Signed-off-by: Suraj <suraj@atheros.com>
> >>
> >>---
> >> drivers/bluetooth/Kconfig | 14 ++
> >> drivers/bluetooth/Makefile | 1 +
> >> drivers/bluetooth/hci_ath.c | 378 +++++++++++++++++++++++++++++++++++++++++
> >> drivers/bluetooth/hci_ldisc.c | 6 +
> >> drivers/bluetooth/hci_uart.h | 8 +-
> >> 5 files changed, 406 insertions(+), 1 deletions(-)
> >> create mode 100755 drivers/bluetooth/hci_ath.c
> >>
..snip..
> >>+
> >>+static void ath_check_data_len(struct ath_struct *ath, int len)
> >>+{
> >>+ int room = skb_tailroom(ath->rx_skb);
> >>+
> >>+ BT_DBG("len %d room %d", len, room);
> >>+
> >>+ if (len > room) {
> >>+ BT_ERR("Data length is too large");
> >>+ kfree_skb(ath->rx_skb);
> >>+ ath->rx_state = HCIATH_W4_PACKET_TYPE;
> >>+ ath->rx_skb = NULL;
> >>+ ath->rx_count = 0;
> >>+ } else {
> >>+ ath->rx_state = HCIATH_W4_DATA;
> >>+ ath->rx_count = len;
> >>+ }
> >>+}
> >>+
> >>+/* Recv data */
> >>+static int ath_recv(struct hci_uart *hu, void *data, int count)
> >>+{
> >>+ struct ath_struct *ath = hu->priv;
> >>+ char *ptr = data;
> >>+ struct hci_event_hdr *eh;
> >>+ struct hci_acl_hdr *ah;
> >>+ struct hci_sco_hdr *sh;
> >>+ int len, type, dlen;
> >>+
> >>+ BT_DBG("hu %p count %d rx_state %d rx_count %d", hu, count,
> >>+ ath->rx_state, ath->rx_count);
> >>+
> >>+ while (count) {
> >>+ if (ath->rx_count) {
> >>+
> >>+ len = min_t(unsigned int, ath->rx_count, count);
> >>+ memcpy(skb_put(ath->rx_skb, len), ptr, len);
> >>+ ath->rx_count -= len;
> >>+ count -= len;
> >>+ ptr += len;
> >>+
> >>+ if (ath->rx_count)
> >>+ continue;
> >>+ switch (ath->rx_state) {
> >>+ case HCIATH_W4_DATA:
> >>+ hci_recv_frame(ath->rx_skb);
> >>+ ath->rx_state = HCIATH_W4_PACKET_TYPE;
> >>+ ath->rx_skb = NULL;
> >>+ ath->rx_count = 0;
> >>+ continue;
> >>+
> >>+ case HCIATH_W4_EVENT_HDR:
> >>+ eh = (struct hci_event_hdr *)ath->rx_skb->data;
> >
> >Use hci_event_hdr() here like hci_h4.c does.
> >
> >>+
> >>+ BT_DBG("Event header: evt 0x%2.2x plen %d",
> >>+ eh->evt, eh->plen);
> >>+
> >>+ ath_check_data_len(ath, eh->plen);
> >>+ continue;
> >>+
> >>+ case HCIATH_W4_ACL_HDR:
> >>+ ah = (struct hci_acl_hdr *)ath->rx_skb->data;
> >
> >And hci_acl_hdr() here.
> >
> >>+ dlen = __le16_to_cpu(ah->dlen);
> >>+
> >>+ BT_DBG("ACL header: dlen %d", dlen);
> >>+
> >>+ ath_check_data_len(ath, dlen);
> >>+ continue;
> >>+
> >>+ case HCIATH_W4_SCO_HDR:
> >>+ sh = (struct hci_sco_hdr *)ath->rx_skb->data;
> >
> >hci_sco_hdr() here.
> >
> >>+
> >>+ BT_DBG("SCO header: dlen %d", sh->dlen);
> >>+
> >>+ ath_check_data_len(ath, sh->dlen);
> >>+ continue;
> >>+
> >>+ }
> >>+ }
> >>+
> >>+ /* HCIATH_W4_PACKET_TYPE */
> >>+ switch (*ptr) {
> >>+ case HCI_EVENT_PKT:
> >>+ BT_DBG("Event packet");
> >>+ ath->rx_state = HCIATH_W4_EVENT_HDR;
> >>+ ath->rx_count = HCI_EVENT_HDR_SIZE;
> >>+ type = HCI_EVENT_PKT;
> >>+ break;
> >>+
> >>+ case HCI_ACLDATA_PKT:
> >>+ BT_DBG("ACL packet");
> >>+ ath->rx_state = HCIATH_W4_ACL_HDR;
> >>+ ath->rx_count = HCI_ACL_HDR_SIZE;
> >>+ type = HCI_ACLDATA_PKT;
> >>+ break;
> >>+
> >>+ case HCI_SCODATA_PKT:
> >>+ BT_DBG("SCO packet");
> >>+ ath->rx_state = HCIATH_W4_SCO_HDR;
> >>+ ath->rx_count = HCI_SCO_HDR_SIZE;
> >>+ type = HCI_SCODATA_PKT;
> >>+ break;
> >>+
> >>+ default:
> >>+ BT_ERR("Unknown HCI packet type %2.2x", (__u8) *ptr);
> >>+ hu->hdev->stat.err_rx++;
> >>+ ptr++;
> >>+ count--;
> >>+ continue;
> >>+
> >>+ };
> >>+ ptr++;
> >>+ count--;
> >>+
> >>+ /* Allocate packet */
> >>+ ath->rx_skb = bt_skb_alloc(HCI_MAX_FRAME_SIZE, GFP_ATOMIC);
> >>+ if (!ath->rx_skb) {
> >>+ BT_ERR("Can't allocate mem for new packet");
> >>+ ath->rx_state = HCIATH_W4_PACKET_TYPE;
> >>+ ath->rx_count = 0;
> >>+
> >>+ return -ENOMEM;
> >>+ }
> >>+ ath->rx_skb->dev = (void *)hu->hdev;
> >>+ bt_cb(ath->rx_skb)->pkt_type = type;
> >>+ }
> >>+
> >>+ return count;
> >>+}
> >
> >Just out of curiosity. I never worked in the driver world, but is it ok
> >to duplicate lots of code when working with drivers? hci_h4.c and this
> >patch share lots of similar code. ath_recv() and h4_recv() are exactly
> >the same except for one line, the ath->rx_count = 0; at case HCIATH_W4_DATA.
> >Does this line makes real difference? recv() is not the only function
> >duplicating code here.
>
> Let me try to anwer you here. I am also new to the driver world, so
> correct me if I am wrong.
>
> Both drivers do the same job, expect that the ATH driver does
> something more on the data transmit path. So, the receive path does
> the same thing. That is the reason why both looks same. This could
> possibly change later as new feature will be added to the ATH
> protocol.
Ok. I'm thinking if it is not possible create a separated 'lib' with the
common code. That's why I asked about the code duplication. I don't know
how worth it is, since we have only 3 drivers using similar code.
>
>
> The function "hci_recv_fragment()" could potentially replace most of
> the code in the ath_recv() function. But, unfortunately this
> function require the caller to provide the HCI Packet type as
> parameter.
>
> This defeats all the advantage of "hci_recv_fragment()" in a UART
> HCI transport driver as all types of packets are received through
> the same callback. So the caller will have to write the same messy
> code in ath_recv() to find out the packet type negating all the
> advantages of "hci_recv_fragment()".
>
>
> >
> >>+
> >>+static struct hci_uart_proto athp = {
> >>+ .id = HCI_UART_ATH,
> >>+ .open = ath_open,
> >>+ .close = ath_close,
> >>+ .recv = ath_recv,
> >>+ .enqueue = ath_enqueue,
> >>+ .dequeue = ath_dequeue,
> >>+ .flush = ath_flush,
> >>+};
> >>+
> >>+int ath_init(void)
> >>+{
> >>+ int err = hci_uart_register_proto(&athp);
> >>+
> >>+ if (!err)
> >>+ BT_INFO("HCIATH protocol initialized");
> >>+ else
> >>+ BT_ERR("HCIATH protocol registration failed");
> >>+
> >>+ return err;
> >>+}
> >
> >BTW, we never check this return value on hci_ldisc.c, why?
>
> you, are correct. Just thought of keeping the same signature used by
> other protocol. moreover hci_ldisc.c being a common file used by all
> protocol it is possible that somebody want to check the return value
> at later point of time. So, kept it that way so that we do not have
> a problem then :-D
>
> Your thoughts?
Yes, your code is right, the return value should be kept. The problem
is that hci_uart_init() doesn't check any other protocol initialization
(h4, bcsp and ll). My thought is: we really need to check?
Marcel, can you answer that?
> >
> >>+
> >>+int ath_deinit(void)
> >>+{
> >>+ return hci_uart_unregister_proto(&athp);
> >>+}
> >>diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
> >>index 76a1abb..7dd76d1 100644
> >>--- a/drivers/bluetooth/hci_ldisc.c
> >>+++ b/drivers/bluetooth/hci_ldisc.c
> >>@@ -542,6 +542,9 @@ static int __init hci_uart_init(void)
> >> #ifdef CONFIG_BT_HCIUART_LL
> >> ll_init();
> >> #endif
> >>+#ifdef CONFIG_BT_HCIUART_ATH
> >>+ ath_init();
> >>+#endif
> >>
> >> return 0;
> >> }
> >>@@ -559,6 +562,9 @@ static void __exit hci_uart_exit(void)
> >> #ifdef CONFIG_BT_HCIUART_LL
> >> ll_deinit();
> >> #endif
> >>+#ifdef CONFIG_BT_HCIUART_ATH
> >>+ ath_deinit();
> >>+#endif
> >>
> >> /* Release tty registration of line discipline */
> >> if ((err = tty_unregister_ldisc(N_HCI)))
> >>diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
> >>index 50113db..385537f 100644
> >>--- a/drivers/bluetooth/hci_uart.h
> >>+++ b/drivers/bluetooth/hci_uart.h
> >>@@ -33,13 +33,14 @@
> >> #define HCIUARTGETDEVICE _IOR('U', 202, int)
> >>
> >> /* UART protocols */
> >>-#define HCI_UART_MAX_PROTO 5
> >>+#define HCI_UART_MAX_PROTO 6
> >>
> >> #define HCI_UART_H4 0
> >> #define HCI_UART_BCSP 1
> >> #define HCI_UART_3WIRE 2
> >> #define HCI_UART_H4DS 3
> >> #define HCI_UART_LL 4
> >>+#define HCI_UART_ATH 5
> >>
> >> struct hci_uart;
> >>
> >>@@ -91,3 +92,8 @@ int bcsp_deinit(void);
> >> int ll_init(void);
> >> int ll_deinit(void);
> >> #endif
> >>+
> >>+#ifdef CONFIG_BT_HCIUART_ATH
> >>+int ath_init(void);
> >>+int ath_deinit(void);
> >>+#endif
> >>--
> >>1.7.0
> >>
> >>
> >>
> >>
> >>
> >
> >--
> >Gustavo F. Padovan
> >http://padovan.org
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gustavo F. Padovan
http://padovan.org
next prev parent reply other threads:[~2010-04-22 8:59 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-15 5:01 [PATCH] Added support for Atheros AR300x Bluetooth Chip suraj
2010-03-24 5:27 ` suraj
2010-03-29 9:01 ` suraj
[not found] ` <1271673889.19858.4.camel@atheros013-desktop>
2010-04-19 18:11 ` Support " Luis R. Rodriguez
2010-03-31 10:59 ` [PATCH] Added Host level support for Atheros AR3xxx " suraj
2010-04-19 23:53 ` [PATCH] Added support for Atheros AR300x " Gustavo F. Padovan
2010-04-20 10:20 ` [PATCH v3] " suraj
2010-04-20 15:36 ` Gustavo F. Padovan
2010-04-20 17:34 ` Luis R. Rodriguez
2010-04-21 4:21 ` Suraj Sumangala
2010-04-21 10:22 ` [PATCH v4] Add support for the " suraj
2010-04-21 17:30 ` Luis R. Rodriguez
2010-04-22 6:10 ` Gustavo F. Padovan
2010-04-22 6:54 ` Suraj Sumangala
2010-04-22 8:59 ` Gustavo F. Padovan [this message]
2010-04-22 9:10 ` [PATCH v5] " suraj
2010-04-26 11:00 ` suraj
2010-04-27 6:19 ` [PATCH] New Firmware for Atheros bluetooth chipset AR3011 suraj
2010-04-27 8:28 ` [PATCH] patch to request new firmware for AR3011 Chip suraj
2010-04-27 15:55 ` Luis R. Rodriguez
2010-05-11 9:04 ` [PATCH v2] ath3k: add support for new firmware suraj
2010-05-05 12:33 ` [PATCH v5] Add support for the Atheros AR300x Bluetooth Chip suraj
2010-05-06 7:45 ` buffer starvation with multiple ACL link suraj
2010-05-20 16:02 ` Marcel Holtmann
2010-05-10 20:12 ` [PATCH v5] Add support for the Atheros AR300x Bluetooth Chip Luis R. Rodriguez
2010-05-11 8:29 ` suraj
2010-05-18 11:39 ` suraj
2010-05-12 13:47 ` [PATCH v3] hciattach application support for " suraj
2010-05-20 13:37 ` suraj
2010-05-20 16:00 ` Marcel Holtmann
2010-05-21 5:01 ` Suraj Sumangala
2010-05-21 7:34 ` Marcel Holtmann
2010-05-20 16:09 ` [PATCH v5] Add support for the " Marcel Holtmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100422085922.GG22959@vigoh \
--to=gustavo@padovan.org \
--cc=Jothikumar.Mothilal@Atheros.com \
--cc=Luis.Rodriguez@Atheros.com \
--cc=Suraj.Sumangala@Atheros.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=suraj@atheros.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).