Am 22.01.2016 um 21:12 schrieb One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx>: >> I would have expected that the main (and IMO sufficient) reason why >> the kernel should do it is because the particular bus used to connect >> a BT chip to the CPU is a hw detail that a kernel that does its job >> should keep to itself. Same as userspace not needing to care if a BT >> chip is behind SDIO or USB, why does it have to tell the kernel behind >> which UART a BT chip is sitting? > > Lots of reasons, some historic some not > > 1. Different BT chips have different interfaces, especially when it gets > to stuff like firmware reprogramming HCI protocol is quite standardized. And firmware reprogramming is rarely done. If it is needed, each chip type can have its own driver module that knows how to inject firmware. This just needs a decent kernel API for a chip driver to communicate with the chip. For SDIO connected WiFi chips it appears that firmware download done by kernel modules is a standard solution. > > 2. In many cases we don't know at the kernel level where there are BT > uarts. It's improving with recent ACPI but for many systems it's simply > not available to the OS We just need to describe the connection of some peer driver to some UART by means of DT. Then, kernel level can know. > > 3. The power management for a lot of BT (especially on device tree) is > not actually expressed, so you need a slightly customised daemon for each > device - that one is ugly but the serial and bt layers can't fix it. The peer chip driver (not the serial or bt layers) could fix it. With help from bt and serial layers. > > 4. Because you don't want to just automatically load and turn on > bluetooth just because it is there - it burns power That is obviously something nobody wants. If the chip must be turned on (or turns on) during boot, the driver can turn it off right after initialization and make the subsystem sleep until activated again. Then it does not burn power although it loads automatically. > > > There is lots of stuff we probe and bind via user space - most things > these days in fact. That's much of why we have notifiers and udev. It's > frequently a win in flexibility, security and configurability to do stuff > via user daemons. We do it for example with all the volume management, > raid and disk encryption. Because volumes are something users really want to configure. They can change their hardware configuration every now and then. And there are removable media to be considered. In our UART cases the underlaying hardware can't be reconfigured. So there is no need to load this burden of config to the user. For BT or GPS I just want it to work the same on all devices (independently on how the specific chip is connected). Kernel should unify such things. Or it would not be a Un(iplexed)ix. -- hns -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
