Messages in this thread | | | Date | Mon, 18 Mar 2024 16:47:07 +0100 | From | Johan Hovold <> | Subject | Re: [PATCH v2 1/4] dt-bindings: bluetooth: add new wcn3991 compatible to fix bd_addr |
| |
On Mon, Mar 18, 2024 at 08:31:09AM -0700, Doug Anderson wrote: > On Mon, Mar 18, 2024 at 8:26 AM Doug Anderson <dianders@google.com> wrote:
> > > A new compatible string (or one-off property) would allow them do make a > > > change when they are ready (e.g. by only updating the devicetrees after > > > all boot firmware has been patched and pushed out). > > > > I have no real opinion about the exact way this is solved so happy to > > let DT folks decide on how they want this. I will note, however, that > > device trees are never shipped separately and thus we have no > > intrinsic need for DT backward compatbility here. It would be OK from > > a ChromeOS perspective to add a property or compatible string for the > > broken case. > > Actually, I should probably say more about this to make it clear how it works. > > Chromebooks ship the kernel as a FIT image which bundles the kernel > and device trees together. The firmware looks at all the bundled > device trees and picks the proper one based on the board name, > revision, and SKU ID. The firmware then looks for the bluetooth node > (I believe it finds it from the "aliases" section) and adds the MAC > address there. > > ...so we could update the DT to add a property (if that's desired) > even if we don't update the firmware.
Thanks for the details. Sounds like we could get away with adding a new property for the broken firmware in this case, which should resolve this nicely without having to deprecate anything.
Could you carry such a devicetree patch out-of-tree until the firmware has been fixed?
Johan
| |