Ok, so it's because in theory the firmware could be buggy and need
patching via the ath3kfw tool (which gosh I really should just import
into -head already) before it starts up.
can you clone https://github.com/erikarn/ath3k and try to load in what
it thinks the right patch set / config file is? See if it comes up ok?
Now that we have the hotplug work from warner and others I bet we could
import ath3k and just have it autorun via devd in a non-terrible
fashion.
Thanks, I can try out the newer ath3kfw tool and see if it has any better
luck loading my firmware than the one already in the tree. But that
doesn't really address my issue, which is that a bunch of devices were
removed from ng_ubt.
Just to be clear, for my personal device, I can load a working firmware
right now; but even if I do, the device is unusable because ng_ubt refuses
to attach to it. When I revert the commit that removed support for it, my
device works fine. So I'm not sure what useful information it would give
to see if the new ath3kfw tool works for me; I still need the fix to
ng_ubt in order to actually use my device.
Even in the cases where the firmware is buggy and needs patching, the
worst that could happen when you try to load it is that the bluetooth card
just doesn't work, right? So my question is still why it's better to
completely remove support rather than just let the user try to use the
device, which might indeed work (as my device does)?
If I'm misunderstanding the potential problem in trying to proceed with
potentially buggy firmware, please let me know.
Thanks.
-Jason
_______________________________________________
freebsd-bluetooth@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscr...@freebsd.org"
