tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: btuart and SOCKET Bluetooth CF

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 */



From: Iain Hibbert <>
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)

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) {
         sc->sc_hci_input = hci_input_acl;
         sc->sc_stats_rx = &sc->sc_stats.acl_rx;
         sc->sc_hci_input = hci_input_sco;
         sc->sc_stats_rx = &sc->sc_stats.sco_rx;
         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_state = BTUART_RECV_PKT_TYPE;
         sc->sc_want = 1;
         sc->sc_rxp = NULL;

> 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.  ;-<


Home | Main Index | Thread Index | Old Index