Re: btuart and SOCKET Bluetooth CF

[KIYOHARA Takashi <kiyohara%kk.iij4u.or.jp@localhost>]

Hi! Iain,


First of all, I changed as follows.

In case cmd_pkt--- 

static void
btuart_dtl_output_cmd(device_t self, struct mbuf *m)
{
    :
        m_adj(m, sizeof(uint8_t));      /* remove hci_cmd_hdr_t's type */
        M_PREPEND(m, sizeof(struct btuart_dtl_header), M_WAITOK);
        dtlh = mtod(m, struct btuart_dtl_header *);
        dtlh->type = HCI_CMD_PKT | BTUART_DTL_HEADER_TYPE;
        dtlh->rsvd = 0;
        dtlh->len = m->m_pkthdr.len - sizeof(struct btuart_dtl_header);
        if (m->m_pkthdr.len & 0x1)
                m_copyback(m, m->m_pkthdr.len, 1, &dtlh->rsvd); /* Add pad */
    :
}

---

However...


From: Iain Hibbert <plunky%rya-online.net@localhost>
Date: Wed, 20 Jan 2010 11:03:43 +0000 (GMT)

> On Wed, 20 Jan 2010, KIYOHARA Takashi wrote:
> 
> > In my opinion, I think that NOKIA DTL is subspecies of btuart(H4). This
> > header is only a little different.  Therefore, I feel that it is strange
> > to prepare a line discipline new different for NOKIA DTL.

> with the DTL it is much simpler - we don't care about the packet contents
> at this level because we can always know the length of the packet. All the
> 7 states are not needed, as 2 only are sufficient (header & data)

hmm...
Five states are necessary for NOKIA DTL.  If NOKIA DTL is supported in two
states, it is should support btuart in five states.

    switch (sc->sc_state) {
    case BTUART_RECV_PKT_TYPE:
         :
    case BTUART_RECV_ACL_HDR:
         sc->sc_hci_input = hci_input_acl;
         sc->sc_stats_rx = &sc->sc_stats.acl_rx;
         :
    case BTUART_RECV_SCO_HDR:
         sc->sc_hci_input = hci_input_sco;
         sc->sc_stats_rx = &sc->sc_stats.sco_rx;
         :
    case BTUART_RECV_EVENT_HDR:
         sc->sc_hci_input = hci_input_event;
         sc->sc_stats_rx = &sc->sc_stats.evt_rx;
         :
    case BTUART_RECV_DATA:      /* Packet Complete */
         if (!sc->sc_hci_input(sc->sc_unit, sc->sc_rxp))
               sc->sc_stats.err_rx++;
         *sc->sc_stats_rx++;
         sc->sc_state = BTUART_RECV_PKT_TYPE;
         sc->sc_want = 1;
         sc->sc_rxp = NULL;
         break;
    }


> These drivers are only a line filter and it makes no sense to me to start
> a wrong filter then apply a correction when we could just start the
> correct one in the beginning. There is a little autoconf glue the same it
> is true, but the thing which is different (the IO routines) are the
> majority of the driver..

A little more brief description, please.  I do not understand your
explanation.  ;-<

Thanks,
--
kiyohara