Hi Adam, >>>>>>> This moves all remaining users of the legacy TI_ST driver to hcill >>>>>>> (patches >>>>>>> 1-3). Then patches 4-7 convert wl128x-radio driver to a standard >>>>>>> platform >>>>>>> device driver with support for multiple instances. Patch 7 will result >>>>>>> in >>>>>>> (userless) TI_ST driver no longer supporting radio at runtime. Patch >>>>>>> 8-11 do >>>>>>> some cleanups in the wl128x-radio driver. Finally patch 12 removes the >>>>>>> TI_ST >>>>>>> specific parts from wl128x-radio and adds the required infrastructure >>>>>>> to use it >>>>>>> with the serdev hcill driver instead. The remaining patches 13 and 14 >>>>>>> remove >>>>>>> the old TI_ST code. >>>>>>> >>>>>>> The new code has been tested on the Motorola Droid 4. For testing the >>>>>>> audio >>>>>>> should be configured to route Ext to Speaker or Headphone. Then you >>>>>>> need to >>>>>>> plug headphone, since its cable is used as antenna. For testing there >>>>>>> is a >>>>>>> 'radio' utility packages in Debian. When you start the utility you need >>>>>>> to >>>>>>> specify a frequency, since initial get_frequency returns an error: >>>>>> >>>>>> What is the status of this series? >>>>>> >>>>>> Based on some of the replies (from Adam Ford in particular) it appears >>>>>> that >>>>>> this isn't ready to be merged, so is a v2 planned? >>>>> >>>>> Yes, a v2 is planned, but I'm super busy at the moment. I don't >>>>> expect to send something for this merge window. Neither LogicPD >>>>> nor IGEP use FM radio, so I can just remove FM support from the >>>>> TI_ST framework. Converting those platforms to hci_ll can be done >>>>> in a different patchset. >>>>> >>>>> If that was the only issue there would be a v2 already. But Marcel >>>>> Holtmann suggested to pass the custom packet data through the BT >>>>> subsystem, which is non-trivial (at least for me) :) >>>> >>>> I am running some tests today on the wl1283-st on the Logic PD Torpedo >>>> board. Tony had suggested a few options, so I'm going to try those. >>>> Looking at those today. If/when you have a V2, please CC me on it. If >>>> it's been posted, can you send me a link? I would really like to see >>>> the st-kim driver go away so I'd like to resolve the issues with the >>>> torpedo board. >>> >>> I have run a bunch of tests on the 5.1 kernel. I am able to get the >>> firmware to load now and the hci0 goes up. I was able to establish a >>> BLE connection to a TI Sensor Tag and read and write data to it with >>> good success on the wl1283. >>> >>> Unfortunately, when I tried to do some more extensive testing over >>> classic Bluetooth, I got an error that repeats itself at seemingly >>> random intervals: >>> Bluetooth: hci0: Frame reassembly failed (-84) >>> >>> I can still scan and pair, but these Frame reassembly failed errors >>> appear to come and go. >> >> there are only 3 places in h4_recv_buf that return EILSEQ. Just add an extra >> printk to these to figure out which one it is. Maybe it is just extra packet >> types that we need to handle. If it is not the packet type one, print what >> packet we have that is causing this. >> > > I added some code around > > /* Check for invalid packet type */ > if (!skb) { > printk("Check for invalid packet type %x\n", (unsigned int) > (&pkts[i])->type); > return ERR_PTR(-EILSEQ); > } > > I don't know if I did it right or I am reading the packet type > correctly, but the frame reassembly errors are being caught here. > > [ 408.519165] Check for invalid packet type ff > [ 408.523559] Bluetooth: hci0: Frame reassembly failed (-84)
so now we need to figure our on how to handle HCI_VENDOR_PKT. #define LL_RECV_VENDOR \ .type = HCI_VENDOR_PKT, \ .hlen = aaa, \ .loff = bbb, \ .lsize = ccc, \ .maxlen = ddd static const struct h4_recv_pkt ll_recv_pkts[] = { ... { LL_RECV_WAKE_ACK, .recv = ll_recv_frame }, { LL_RECV_VENDOR, .recv = hci_recv_diag }, }; Can you hexdump the data inside the skb and we can figure out what it uses for the header and size. In hci_bcm.c there are a few examples of fixed size packets and bpa10x.c contains one where it follows an actual header definition. Also hci_nokia.c contains a few for their packets. Regards Marcel