On Mon, Feb 7, 2011 at 4:24 PM, Ville Tervo <ville.tervo@xxxxxxxxx> wrote:
> Hi Pavan,
>
> On Mon, Feb 07, 2011 at 04:38:52AM -0600, ext pavan_savoy@xxxxxx wrote:
>> From: Pavan Savoy <pavan_savoy@xxxxxx>
>>
>> Gustavo,
>>
>> As suggested, the modifications to TI ST driver to remove the bluetooth
>> references have been made and the changes have been merged to the
>> linux-next tree.
>>
>> Find below the patch for the btwilink driver,
>> I have taken care of your following comments,
>> 1. channel IDs and the offsets are now being taken from the
>> header file hci.h.
>> 2. removed the un-necessary BT_ERR.
>> 3. changed the order during return from st_register.
>> 4. continue to unregister even if 1st unregister fails.
>>
>> Please review and provide comments,
>
> Will do. Some comment
>
>> +/* Called from HCI core to initialize the device */
>> +static int ti_st_open(struct hci_dev *hdev)
>> +{
>> + Â Â unsigned long timeleft;
>> + Â Â struct ti_st *hst;
>> + Â Â int err, i;
>> +
>> + Â Â BT_DBG("%s %p", hdev->name, hdev);
>> +
>> + Â Â if (test_and_set_bit(HCI_RUNNING, &hdev->flags))
>> + Â Â Â Â Â Â return -EBUSY;
>> +
>> + Â Â /* provide contexts for callbacks from ST */
>> + Â Â hst = hdev->driver_data;
>> +
>> + Â Â for (i = 0; i < MAX_BT_CHNL_IDS; i++) {
>> + Â Â Â Â Â Â ti_st_proto[i].priv_data = hst;
>> + Â Â Â Â Â Â ti_st_proto[i].max_frame_size = HCI_MAX_FRAME_SIZE;
>> +
>> + Â Â Â Â Â Â err = st_register(&ti_st_proto[i]);
>> + Â Â Â Â Â Â if (!err)
>> + Â Â Â Â Â Â Â Â Â Â goto done_downloading_firmware;
>> +
>> + Â Â Â Â Â Â if (err != -EINPROGRESS) {
>> + Â Â Â Â Â Â Â Â Â Â clear_bit(HCI_RUNNING, &hdev->flags);
>> + Â Â Â Â Â Â Â Â Â Â BT_ERR("st_register failed %d", err);
>> + Â Â Â Â Â Â Â Â Â Â return err;
>> + Â Â Â Â Â Â } else {
>
> No need for else. Less indentation looks better to me at least.
OK, can do this.
>> + Â Â Â Â Â Â Â Â Â Â /* ST is busy with either protocol
>> + Â Â Â Â Â Â Â Â Â Â Â* registration or firmware download.
>> + Â Â Â Â Â Â Â Â Â Â Â*/
>> + Â Â Â Â Â Â Â Â Â Â /* Prepare wait-for-completion handler data structures.
>> + Â Â Â Â Â Â Â Â Â Â */
>> + Â Â Â Â Â Â Â Â Â Â init_completion(&hst->wait_reg_completion);
>
> init_completion should be done before startin action which executes complete().
> IOW this should be before st_register if I understood this correctly.
>
> Otherwise the started action might call complete before init_completion and
> wait_for_completion_timeout will just time even everything went fine.
Humn, May be, However I would want to wait only when I am supposed to,
As in if EINPROGRESS happens (i.e firmware is already being downloaded because
of say FM or GPS..) then I would want to wait, Or else - I continue.
But Yes, may be having the INIT_COMPLETION before would not hurt in
that case either. (Haven't seen it fail though !! - even after testing
FM/GPS with BT multiple times..)
> --
> Ville
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at Âhttp://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
