Re: [PATCH v4] Bluetooth: btwilink driver

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Marcel Holtmann
Date: Tuesday, November 9, 2010 - 11:08 pm

Hi Pavan,


please do this properly. Just write it like this:

	struct hci_dev *hdev = hst->hdev;
+

I really prefer if the variable with the assignment comes first.


Don't do this cast. See the other drivers where we just use (void *)
cast.


So first of all, I prefer if you check like this:

	if (err < 0) {

And then second, you are double freeing the SKB here. The hci_recv_frame
will free the SKB in an error case.


Please don't bother with NULL assignment. It should not be needed.


I really don't like what you are doing here. So please use
test_and_set_bit and clear it in an error case.

Also you need to handle all error cases. Just not only two.

Where is the ti_st_proto.write coming from?


You need a test_and_clear_bit for HCI_RUNNING. There is a huge imbalance
here. Have you tested this with consecutive hciconfig hci0 up/down
executions actually?


Pointless check. The core will not call this function with a NULL
pointer SKB.


Even this can't really happen. Have you seen such a case?


I don't like these crappy checks on every packet. That is just stupid.
You have checked for st_write when open happens and you set the hdev to
HCI_RUNNING. Are you saying this could change during the lifetime of the
hdev? If so then you have a serious problem here.


What is the reason for this deferred stats update. That code looks
pretty much hackish to me.


What are you checking here for? Why do you think that hdev would not be
valid? This is what the btusb and btsdio drivers do:

static void btusb_destruct(struct hci_dev *hdev)
{
        struct btusb_data *data = hdev->driver_data;

        BT_DBG("%s", hdev->name);

        kfree(data);
}



I prefer if err is last in the variable list.


Please implement a flush callback.


Why do you need this? This should only be crappy devices. Something like
Bluetooth 1.0b old devices.


No double empty lines please.


See above.


This should be in the module_init function. And should be a BT_INFO and
be precise what driver this actually this.


Is this ti_st_register device use anywhere else. Then please just
include that code in here to make this clear. All other drivers do all
the work in their probe() callback.


Here I would prefer this:

	struct ti_st *hst = dev_get_drvdata(&pdev->dev);


That comment doesn't match what you are doing here.


No need to check for hdev here. If probe fails, then remove should never
be called, right?

And just to be safe you might wanna add this:

	dev_set_drvdata(&pdev->dev, NULL);


please just do like we do with all other drivers;

	BT_INFO(...)

	return platform_driver_register(&btwilink_driver);


And this should be btwilink_init and btwilink_exit. Please don't try to
grab some generic namespace.


As mentioned above, that one seems wrong to me. You need to know what
your device supports. And by default it should allow sending HCI_Reset
at init. If not, then just that quirk. No need for module parameter
here.


Regards

Marcel


--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH v4] Bluetooth: btwilink driver, pavan_savoy, (Tue Oct 19, 3:06 pm)
Re: [PATCH v4] Bluetooth: btwilink driver, Pavan Savoy, (Thu Oct 21, 6:26 am)
RE: [PATCH v4] Bluetooth: btwilink driver, Savoy, Pavan, (Tue Oct 26, 8:49 am)
Re: [PATCH v4] Bluetooth: btwilink driver, Marcel Holtmann, (Tue Nov 9, 11:08 pm)