Hi Alan, >>> That would still be a regression. Not everyone even uses the kernel >>> bluetooth stack. It would only return EBUSY if you had done an "up" >>> on it via the direct bluetooth stack. >> >> So it returns EBUSY when uart-bus is used. Since uart-bus is about >> hardwired devices that's basically always. > > That would only be when the bluetooth port in question was active via the > hardwired interface - which is not always. You choose to turn on/off > bluetooth interfaces. If you boot with an older user space you'd use > hciattach instead. > > In many cases you'll also still need the tty interface to do things like > firmware upgrades. actually for Bluetooth you don't. We dealt with all of this crazy vendor stuff and provided proper hooks in the Bluetooth subsystem to support. hciattach / btattach are just the hotplug trigger to attach the hardware. It is like plugging in an USB dongle into your USB port. That is how you have to see this. Killing the hciattach / btattach process is the unplug event. It is that simple. And if you can skip the hciattach / btattach step and use kernel serial bus with proper enumeration and driver binding, then the end result is that you get a hci0 Bluetooth interface. The same way as you would have gotten when calling hciattach / btattach. Meaning you then call hciconfig hci0 up (or let bluetoothd do it for you) and you have Bluetooth working. It worked this way since 2.4.6 kernel. The real power on is done via hciconfig hci0 up and not hciattach. The only difference is that since a long time now, kernel drivers can provide extra vendor hooks. And the kernel can internally and temporally power on the hardware if it has to do certain tasks. For example configuring the BD_ADDR, loading some patches or doing some audio configuration. Regards Marcel -- 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
