Return-Path: MIME-Version: 1.0 In-Reply-To: References: <20100924230730.GB6566@tux> <1286266981.17473.33.camel@aeonflux> <20101005192814.GB11831@tux> <1286308731.2588.13.camel@aeonflux> <1286349552.6145.11.camel@aeonflux> <1286380566.6145.42.camel@aeonflux> <20101006163816.GE7070@tux> <20101006173949.GG7070@tux> <1286387660.3655.382.camel@jlt3.sipsolutions.net> From: "Luis R. Rodriguez" Date: Wed, 6 Oct 2010 11:26:14 -0700 Message-ID: Subject: Re: RFC: btusb firmware load help To: Johannes Berg Cc: Marcel Holtmann , Luis Rodriguez , linux-bluetooth , "linux-kernel@vger.kernel.org" , "linux-wireless@vger.kernel.org" , Deepak Dhamdhere , Sree Durbha Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Wed, Oct 6, 2010 at 11:22 AM, Luis R. Rodriguez wrote: > On Wed, Oct 6, 2010 at 10:54 AM, Johannes Berg > wrote: >> On Wed, 2010-10-06 at 10:39 -0700, Luis R. Rodriguez wrote: >> >> >>> > With sflash based AR3011 hardware, when we connect the device to USB >>> > port it gets detected as a Bluetooth device because of firmware in >>> > Flash (VID=0x0CF3, PID=0x3002). This triggers the Bluetooth sub >>> > system driver (btusb.ko) directly in the host instead of ath3k >>> > DFU driver. Therefore, there is no firmware downloaded in to the >>> > RAM to bring up Bluetooth at this point. This is the problem >>> > we're trying to "fix". >> >> So the easiest fix for this would be to >>  a) ignore 0x0cf3,0x3002 in btusb >>  b) add it to ath3k firmware loading >>  c) change the ath3k firmware to load with 0x0cf3,0x3003 (or whatever >>    else you want, as long as it's not 0x3000 and not 0x3002) >> >> Then the ignore in btusb won't affect ath3k after that new firmware was >> loaded. > > Good idea, I forgot about possible firmware changes :) Lets see if our > team can do that. Thanks for all the feedback. Deepak a proof of concept test can involve simply hex-editing the ath3k-1.fw and replacing 0x3002 to 0x3003, then the above patch might work. Luis