On Tue, Jan 2, 2018 at 11:11 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > Hi Martin, > >> Some Realtek bluetooth devices need a "config" blob. The btrtl driver >> currently only allows loading this config blob via the request_firmware >> mechanism. >> >> The UART Bluetooth chips use this config blob to specify the baudrate, >> whether flow control is used and some other unknown bits. This means >> that the config blob is board-specific - thus loading it via >> request_firmware means that the rootfs is tied to a specific board. >> >> The UART Bluetooth chips are implemented through serdev. This means >> there is also a devicetree node which describes the Bluetooth chip. >> Thus we can also load the blob from the devicetree node to keep the >> filesystem independent of any board configuration data. In the future >> this could be extended to support ACPI as well (in case that's needed). >> >> Parse the devicetree node if it exists and obtain the config blob from >> there. Otherwise fall back to using the "old" request_firmware >> mechanism. > > where are these config blobs coming from? I think we also need to give people a helping hand on how to add them to DT. I still wonder if the only pieces we are using are the UART config, then maybe skipping the config blob and allowing for clear named values in DT might be better. What about x86 platforms where we do not have DT (I didn't check but I don't think that the UART config in that case is shipped in the ACPI tables)? Cheers, -- Carlo Caione | +44.7384.69.16.04 | Endless -- 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
