Return-Path: MIME-Version: 1.0 In-Reply-To: <20110121171857.GC2400@joana> References: <1294138788-10307-1-git-send-email-pavan_savoy@ti.com> <20110121171857.GC2400@joana> Date: Fri, 21 Jan 2011 23:10:28 +0530 Message-ID: Subject: Re: [RFC 0/2] remove BT references from TI_ST From: Pavan Savoy To: "Gustavo F. Padovan" Cc: marcel@holtmann.org, linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org Content-Type: text/plain; charset=UTF-8 List-ID: Gustavo, On Fri, Jan 21, 2011 at 10:48 PM, Gustavo F. Padovan wrote: > Hi Pavan, > > * Pavan Savoy [2011-01-19 23:56:29 +0530]: > >> Gustavo, >> >> On Tue, Jan 4, 2011 at 4:29 PM, =C2=A0 wrote: >> > From: Pavan Savoy >> > >> > Gustavo, >> > >> > Based on your comments, that the underlying shared transport driver >> > for btwilink driver made use of the BT references to peek into the pac= kets >> > 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 assem= bled >> data or assemble fragmented data. >> >> Please have a look, Please suggest whether something like this is requir= ed, >> 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 whi= ch >> > 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 aroun= d, >> > 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 an= d 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 >