Gustavo, On Fri, Jan 21, 2011 at 10:48 PM, Gustavo F. Padovan <padovan@xxxxxxxxxxxxxx> wrote: > Hi Pavan, > > * Pavan Savoy <pavan_savoy@xxxxxxxx> [2011-01-19 23:56:29 +0530]: > >> Gustavo, >> >> On Tue, Jan 4, 2011 at 4:29 PM, Â<pavan_savoy@xxxxxx> wrote: >> > From: Pavan Savoy <pavan_savoy@xxxxxx> >> > >> > Gustavo, >> > >> > Based on your comments, that the underlying shared transport driver >> > for btwilink driver made use of the BT references to peek into the packets >> > I have modified the TI_ST. >> >> Since there lacks a generic way to parse the packets coming in from the >> UART into BT, FM or GPS, we have to look into the data to fragment assembled >> data or assemble fragmented data. >> >> Please have a look, Please suggest whether something like this is required, >> If not, please also suggest, if including BT headers is a problem ? > > Not really. The real problem is to break the abstraction between drivers > layers (core and bluetooth drivers in this case) ok, fine. Although I myself personally would prefer the older way ... But its fine, I understand why references to bluetooth headers doesn't look good at shared transport level... >> >> Because I just include the BT headers and don't have a build >> dependency as such on >> BT/HCI and don't use any functions from hci_core in my shared transport driver. >> >> > For this reason, Now the above lying protocol drivers like BT, FM and GPS >> > would send details about their packet types and header information which >> > would assist shared transport driver to parse the data. > > Fair enough. This new approach is way better. Ok, So there is no problem with BT driver doing this multiple calls to st_register (or a single call with info array of ACL, SCO, Event to st_register) ? This would only hold true for BT. For FM or GPS there would be only 1 set of info sent across from protocol drivers to the shared transport drivers... Also, during firmware download, is hard-coding of few parameters pertaining to HCI-Event alright ? because this needs to happen even if say BT doesn't plan to use the shared transport and only FM V4L2 is at works.. >> > >> > Gustavo, please also notice the change in btwilink driver in and around, >> > st_register and suggest if something like this is OK. >> > btwilink can also be modified to send in all the packet specific data >> > in one shot, if that is preferred. >> > >> > Please review and provide comments.. >> > >> > Note: >> > If this is alright, I will send out a modified patch with updated >> > subject to lkml/Greg for linux-next. > > Ok. Go ahead. Then tell me when I'll be able to apply your patch. (I need to > have the core modifications in my tree first). Or I just ack the patch and it > finds its way to mainline through Greg's tree. Yes, I will post a patch to lkml against linux-next to greg KH, and based on that send a separate patch to linux-bluetooth for the btwilink.. > -- > Gustavo F. Padovan > http://profusion.mobi > -- 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
