Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751294AbcCAQcT (ORCPT ); Tue, 1 Mar 2016 11:32:19 -0500 Received: from [82.165.8.211] ([82.165.8.211]:47684 "EHLO mail.holtmann.org" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750921AbcCAQcS convert rfc822-to-8bit (ORCPT ); Tue, 1 Mar 2016 11:32:18 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Atheros 0cf3:3004 duplicate bluetooth device From: Marcel Holtmann In-Reply-To: <56D58217.2050500@gmail.com> Date: Tue, 1 Mar 2016 08:32:12 -0800 Cc: "Gustavo F. Padovan" , Johan Hedberg , linux-bluetooth , linux-kernel Content-Transfer-Encoding: 8BIT Message-Id: References: <56D58217.2050500@gmail.com> To: Dmitry Tunin X-Mailer: Apple Mail (2.3112) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2023 Lines: 44 Hi Dmitry, > We have a problem with Atheros 0cf3:3004 devices. > > Atheros people re-used the PID for a new Rome device. > > This is a Rome device: > > T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 > D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=0cf3 ProdID=3004 Rev=00.01 > C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA > I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) > I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) > > > This is a pre-rome AR3012 device: > > T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=05 Dev#= 8 Spd=12 MxCh= 0 > D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=0cf3 ProdID=3004 Rev=00.02 > S: Manufacturer=Atheros Communications > S: Product=Bluetooth USB Host Controller > S: SerialNumber=Alaska Day 2006 > C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA > I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > > As you can see, there is nothing we can really base on. Revision does not help, because there could be other AR3012 devices with Rev 00.01. > > An option could be to use this PID as a Rome in new kernels. But that will cause regressions for old devices. > > My opinion is that this can't be fixed at the kernel level. For distros it is possible to provide DKMS drivers, specific to the Rome. > But it will be a bit hard to maintain. > > What do you thing as the last authority in this case? I think one of the Qualcomm guys needs to come and tell us what is going on here and what are the options. Maybe it is possible to send a vendor HCI command or vendor USB command to identify the device correctly. We do now have the hdev->setup and even inside the USB driver, we have a pre-stage of its own. There is a chance to actually merge some of the ath3k stuff back into btusb with offloading the Qualcomm specific pieces into a separate library modules (like we do with btintel, btbcm etc.). Regards Marcel