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
