Return-Path: MIME-Version: 1.0 In-Reply-To: <563D6F9F-8495-40D4-BE56-5338ED2B9B99@holtmann.org> References: <20180101204217.26165-1-martin.blumenstingl@googlemail.com> <20180101204217.26165-8-martin.blumenstingl@googlemail.com> <563D6F9F-8495-40D4-BE56-5338ED2B9B99@holtmann.org> From: Carlo Caione Date: Tue, 2 Jan 2018 11:15:59 +0000 Message-ID: Subject: Re: [RFC v2 7/9] bluetooth: btrtl: load the config blob from devicetree when available To: Marcel Holtmann Cc: Martin Blumenstingl , Rob Herring , devicetree , "open list:BLUETOOTH DRIVERS" , linux-serial@vger.kernel.org, Mark Rutland , "Gustavo F. Padovan" , Johan Hedberg , gregkh@linuxfoundation.org, jslaby@suse.com, johan@kernel.org, linux-amlogic@lists.infradead.org, Larry.Finger@lwfinger.net, Daniel Drake Content-Type: text/plain; charset="UTF-8" List-ID: On Tue, Jan 2, 2018 at 11:11 AM, Marcel Holtmann wrot= e: > 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 pe= ople a helping hand on how to add them to DT. I still wonder if the only pi= eces 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, --=20 Carlo Caione | +44.7384.69.16.04 | Endless