Hi, On Mon, Mar 18, 2024 at 8:47 AM Johan Hovold <johan@xxxxxxxxxx> wrote: > > 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? IMO we shouldn't try to fix the firmware at all. Given the fact that it took me a year to get a firmware uprev completed for one trogdor variant for fixes that actually had functional impact, it's possible we'll never actually get an uprev completed that includes this fix or it will happen years from now when nobody remembers about it. I'm also certain this whole issue will also cause a bunch of debugging over the years if we try to fix it in firmware like that. There are cases where people end up running with old firmware since the developer workflow doesn't automatically update it. The handling should be added upstream and we should just accept that the trogdor firmware gets it backward. -Doug
