From owner-freebsd-bluetooth@freebsd.org Thu Mar 26 02:06:17 2020 Return-Path: Delivered-To: freebsd-bluetooth@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CD45426D10F for ; Thu, 26 Mar 2020 02:06:17 +0000 (UTC) (envelope-from jason-fbsd-bluetooth@shalott.net) Received: from waffle.shalott.net (waffle.shalott.net [209.151.236.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.shalott.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48npHV3nR8z4FP9 for ; Thu, 26 Mar 2020 02:05:57 +0000 (UTC) (envelope-from jason-fbsd-bluetooth@shalott.net) Received: (qmail 19052 invoked by uid 2034); 26 Mar 2020 02:05:42 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Mar 2020 02:05:42 -0000 Date: Wed, 25 Mar 2020 19:05:40 -0700 (PDT) From: jason-fbsd-bluetooth@shalott.net X-X-Sender: jason@waffle.shalott.net To: freebsd-bluetooth@freebsd.org cc: adrian@freebsd.org, maksim.yevmenkin@gmail.com Subject: Re: ath3k USB bluetooth card not detected by ng_ubt, possible regression In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (LRH 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 48npHV3nR8z4FP9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jason-fbsd-bluetooth@shalott.net designates 209.151.236.43 as permitted sender) smtp.mailfrom=jason-fbsd-bluetooth@shalott.net X-Spamd-Result: default: False [-2.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991,0]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx:shalott.net]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[shalott.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NO_DN(0.00)[]; IP_SCORE(-0.01)[country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11051, ipnet:209.151.224.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 02:06:18 -0000 >> Hello. I am trying to get an ath3k-based USB bluetooth adapter >> working. I previously had this adapter working under FreeBSD, several >> years ago[.] After loading the firmware, it is not detected by ng_ubt. > I tracked this down: > > https://svnweb.freebsd.org/base?view=revision&revision=249178 > > Can someone explain why these devices were blacklisted from the ng_ubt > driver? It seems like the devices will fail to work if the firmware is > not loaded to the device before ng_ubt is loaded into the kernel; but it > seems like the failure mode is just that those devices don't work in > that case. So blacklisting them from the driver seems a lot worse... Pinging again on this. Any chance we can revert the above commit? After reverting the above commit on my box, I am able to fully use my bluetooth adapter (pair HID devices, play audio through my headset with virtual_oss, etc). I don't want to have to maintain a custom kernel in perpetuity to maintain that capability. Am I missing something about the current situation? As far as I can tell, with all of those devices blacklisted in the ng_ubt driver, there is no way to use those devices on FreeBSD. But if those devices are re-instated in ng_ubt, the only downside is that they _might_ not work, because it's left as an exercise to the user to make sure that the device firmware is pushed to the device before ng_ubt is loaded into the kernel. So my understanding is: current situation, those devices are impossible to use; reverting the above commit, those devices might be usable if the user knows what they're doing. Is that the wrong understanding? And if it's correct, is there any reason to not re-instate them? If some other change is needed or wanted instead of just reverting the above commit -- extra checks, warning log messages, etc -- I would be happy to take a run at it if someone could describe what's needed. I don't know anything about Bluetooth and don't have any kernel-hacking experience, but I am an experienced C programmer. Thanks. -Jason