[RFC v2] Bluetooth: Provide access to reassembled Rx packets

[RFC v2] Bluetooth: Provide access to reassembled Rx packets

[Suraj Sumangala]

Provide the HCI transport driver access to reassembled Rx packets before
sending to Host.

Signed-off-by: Suraj Sumangala <suraj@atheros.com>
---
 include/net/bluetooth/hci_core.h |    1 +
 net/bluetooth/hci_core.c         |    4 ++++
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 350b3e6..532169c 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -156,6 +156,7 @@ struct hci_dev {
 	int (*close)(struct hci_dev *hdev);
 	int (*flush)(struct hci_dev *hdev);
 	int (*send)(struct sk_buff *skb);
+	int (*recv)(struct sk_buff *skb);
 	void (*destruct)(struct hci_dev *hdev);
 	void (*notify)(struct hci_dev *hdev, unsigned int evt);
 	int (*ioctl)(struct hci_dev *hdev, unsigned int cmd, unsigned long arg);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 995c9f9..85e09ef 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1132,6 +1132,10 @@ static int hci_reassembly(struct hci_dev *hdev, int type, void *data,
 			/* Complete frame */
 
 			bt_cb(skb)->pkt_type = type;
+
+			if (hdev->recv)
+				hdev->recv(skb);
+
 			hci_recv_frame(skb);
 
 			hdev->reassembly[index] = NULL;
-- 
1.7.0.4

Re: [RFC v2] Bluetooth: Provide access to reassembled Rx packets

[Marcel Holtmann]

Hi Suraj,

> Provide the HCI transport driver access to reassembled Rx packets before
> sending to Host.

you still haven't answered my question on why you want this. It makes no
sense to me to relay all packets back to the driver. That is just a
waste of CPU cycles.

Regards

Marcel

Re: [RFC v2] Bluetooth: Provide access to reassembled Rx packets

[Suraj]

Hi Marcel,

On 7/26/2010 8:43 PM, Marcel Holtmann wrote:
> Hi Suraj,
>
>> Provide the HCI transport driver access to reassembled Rx packets before
>> sending to Host.
>
> you still haven't answered my question on why you want this. It makes no
> sense to me to relay all packets back to the driver. That is just a
> waste of CPU cycles.
>
> Regards
>
> Marcel
>
>

The requirement is simple. The driver need to know the status of certain 
vendor specific commands by checking the parameters of Command complete 
events.

We also have a requirements to verify the status of HCI RESET command to 
update power management feature.

If you are concerned about CPU cycle, we can limit this only for HCI 
events and not for ACL/SCO packets.

Please do let me know if you think there is an alternate way so that the 
HCI transport driver can access to HCI events.

Regards
Suraj

Re: [RFC v2] Bluetooth: Provide access to reassembled Rx packets

[Marcel Holtmann]

Hi Suraj,

> >> Provide the HCI transport driver access to reassembled Rx packets before
> >> sending to Host.
> >
> > you still haven't answered my question on why you want this. It makes no
> > sense to me to relay all packets back to the driver. That is just a
> > waste of CPU cycles.
>
> The requirement is simple. The driver need to know the status of certain 
> vendor specific commands by checking the parameters of Command complete 
> events.

then implement something that handles vendor specific commands and
events properly. This proposal is insane and will not get merged.

> We also have a requirements to verify the status of HCI RESET command to 
> update power management feature.

Then implement something that can track the status of HCI reset
properly.

> If you are concerned about CPU cycle, we can limit this only for HCI 
> events and not for ACL/SCO packets.
> 
> Please do let me know if you think there is an alternate way so that the 
> HCI transport driver can access to HCI events.

So first of all, lets make something perfectly clear. All Bluetooth
drivers are _transport_ drivers. They don't need to know what they are
transporting. And in addition you should not look into the packets that
you are sending or receiving. The Bluetooth core does that HCI packet
parsing.

This is how I want it and how this is going to stay. Everything else is
an insane approach and cost every single driver overhead. In addition
the lifetime rules of SKBs become more and more complicated. That is a
pretty bad thing. It will result in excessive memory usage and will
cause problems.

Regards

Marcel

Re: [RFC v2] Bluetooth: Provide access to reassembled Rx packets

[Suraj]

Hi Marcel,

On 7/27/2010 4:12 AM, Marcel Holtmann wrote:
> Hi Suraj,
>
>>>> Provide the HCI transport driver access to reassembled Rx packets before
>>>> sending to Host.
>>>
>>> you still haven't answered my question on why you want this. It makes no
>>> sense to me to relay all packets back to the driver. That is just a
>>> waste of CPU cycles.
>>
>> The requirement is simple. The driver need to know the status of certain
>> vendor specific commands by checking the parameters of Command complete
>> events.
>
> then implement something that handles vendor specific commands and
> events properly. This proposal is insane and will not get merged.
>
>> We also have a requirements to verify the status of HCI RESET command to
>> update power management feature.
>
> Then implement something that can track the status of HCI reset
> properly.

Is there any option for the transport driver to get status of certain 
commands from the HCI core?

if it is not there, can you advice how that can be done efficiently?

>
>> If you are concerned about CPU cycle, we can limit this only for HCI
>> events and not for ACL/SCO packets.
>>
>> Please do let me know if you think there is an alternate way so that the
>> HCI transport driver can access to HCI events.
>
> So first of all, lets make something perfectly clear. All Bluetooth
> drivers are _transport_ drivers. They don't need to know what they are
> transporting. And in addition you should not look into the packets that
> you are sending or receiving. The Bluetooth core does that HCI packet
> parsing.
If that is the case, should we be implementing something similar to the 
way HCI_LL protocol does it? By defining custom packet types and parsing 
it to get board specific information?

>
> This is how I want it and how this is going to stay. Everything else is
> an insane approach and cost every single driver overhead. In addition
> the lifetime rules of SKBs become more and more complicated. That is a
> pretty bad thing. It will result in excessive memory usage and will
> cause problems.
>
> Regards
>
> Marcel
>
>

Regards
Suraj

Re: [RFC v2] Bluetooth: Provide access to reassembled Rx packets

[Suraj]

Hi Marcel,

On 7/27/2010 4:12 AM, Marcel Holtmann wrote:

> So first of all, lets make something perfectly clear. All Bluetooth
> drivers are _transport_ drivers. They don't need to know what they are
> transporting. And in addition you should not look into the packets that
> you are sending or receiving. The Bluetooth core does that HCI packet
> parsing.
>
> This is how I want it and how this is going to stay. Everything else is
> an insane approach and cost every single driver overhead. In addition
> the lifetime rules of SKBs become more and more complicated. That is a
> pretty bad thing. It will result in excessive memory usage and will
> cause problems.

I understand the point that you are making. But If I am not mistaken, 
HCI transport driver is the only part of the system that could be vendor 
specific ( HCI ATH3K, HCI LL etc). So a vendor specific command or event 
makes more sense to a transport driver than anybody else.

Is there anyway this requirement can be sufficed without causing the 
issues you have mentioned above?
>
> Regards
>
> Marcel
>
>

Regards
Suraj

Re: [RFC v2] Bluetooth: Provide access to reassembled Rx packets

[Marcel Holtmann]

Hi Suraj,

> > So first of all, lets make something perfectly clear. All Bluetooth
> > drivers are _transport_ drivers. They don't need to know what they are
> > transporting. And in addition you should not look into the packets that
> > you are sending or receiving. The Bluetooth core does that HCI packet
> > parsing.
> >
> > This is how I want it and how this is going to stay. Everything else is
> > an insane approach and cost every single driver overhead. In addition
> > the lifetime rules of SKBs become more and more complicated. That is a
> > pretty bad thing. It will result in excessive memory usage and will
> > cause problems.
> 
> I understand the point that you are making. But If I am not mistaken, 
> HCI transport driver is the only part of the system that could be vendor 
> specific ( HCI ATH3K, HCI LL etc). So a vendor specific command or event 
> makes more sense to a transport driver than anybody else.
> 
> Is there anyway this requirement can be sufficed without causing the 
> issues you have mentioned above?

so you might be able to convince me if you implement something proper
for handling vendor commands. The basic assumption is still that a HCI
driver is a pure transport driver.

However you have access to hci_dev. So if you create some functions to
execute vendor commands and retrieve the results then this might be a
way. The core already processes vendor commands and events. But keep in
mind that there is no requirement to get a command status or command
complete event for vendor commands. For example CSR doesn't send them
for their vendor commands.

Regards

Marcel

Re: [RFC v2] Bluetooth: Provide access to reassembled Rx packets

[Suraj]

Hi Marcel,

On 7/27/2010 10:44 AM, Marcel Holtmann wrote:
> Hi Suraj,
>
>>> So first of all, lets make something perfectly clear. All Bluetooth
>>> drivers are _transport_ drivers. They don't need to know what they are
>>> transporting. And in addition you should not look into the packets that
>>> you are sending or receiving. The Bluetooth core does that HCI packet
>>> parsing.
>>>
>>> This is how I want it and how this is going to stay. Everything else is
>>> an insane approach and cost every single driver overhead. In addition
>>> the lifetime rules of SKBs become more and more complicated. That is a
>>> pretty bad thing. It will result in excessive memory usage and will
>>> cause problems.
>>
>> I understand the point that you are making. But If I am not mistaken,
>> HCI transport driver is the only part of the system that could be vendor
>> specific ( HCI ATH3K, HCI LL etc). So a vendor specific command or event
>> makes more sense to a transport driver than anybody else.
>>
>> Is there anyway this requirement can be sufficed without causing the
>> issues you have mentioned above?
>
> so you might be able to convince me if you implement something proper
> for handling vendor commands. The basic assumption is still that a HCI
> driver is a pure transport driver.

My requirement is basically to use the command complete event of 
HCI_RESET to trigger a vendor specific command and verify its status by 
checking the status of the VSC.

So, does it makes sense to register a callback with HCI core with 
required Event ID so that HCI core can call the callback when it 
receives the corresponding Event? This would still make sure that HCI 
packets are handled by HCI core and "driver/whoever registers the 
callback" will be notified by the HCI core as and when required.

Not sure this would address the concern you have raised.

>
> However you have access to hci_dev. So if you create some functions to
> execute vendor commands and retrieve the results then this might be a
> way. The core already processes vendor commands and events. But keep in
> mind that there is no requirement to get a command status or command
> complete event for vendor commands. For example CSR doesn't send them
> for their vendor commands.

Thanks,

>
> Regards
>
> Marcel
>
>

Regards
Suraj