Andre, > -----Original Message----- > From: Andre Guedes [mailto:andre.guedes@xxxxxxxxxxxxx] > Sent: Monday, March 19, 2012 3:55 PM > To: Ganir, Chen > Cc: linux-bluetooth@xxxxxxxxxxxxxxx > Subject: Re: LE/BR/EDR interleaved scanning > > Hi Chen Ganir, > > On Mon, Mar 19, 2012 at 9:55 AM, Ganir, Chen <chen.ganir@xxxxxx> wrote: > > Hi. > > > > The current implementation of the Bluetooth-next interleaved scan > will currently do LE scan , and then BR/EDR scan, although the specs > clearly defines that BR/EDR device search should be performed first, > and only when done, LE device scan should start. Is there a specific > reason why the spec was not followed here ? > > Implementing LE scan first had some advantages: > 1. From the implementation point of view, we don't need to change > anything in BR/EDR discovery neither name resolution code. All logic > in inquiry_complete_event keeps the same. > 2. Doing BR/EDR + LE + name resolution we have a 5.12 sec gap between > finding BR/EDR devices and resolving its names. During LE discovery, > BR/EDR devices may be out of range and we'll waste time trying to > resolve its names. By doing LE scan first, we don't have this problem. > > Besides, we didn't find any constrain in GAP TS spec about that. Also, > the Core spec clearly says performing BR/EDR + LE is just a > recommendation about how to implement interleaving (see Vol 3, page > 386). Thanks for clearing that out. > > BR, > > Andre Chen Ganir Texas Instruments. -- 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
