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@xxxxxxxxxx> 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
