Hi Konrad, On Mon Jun 22, 2026 at 10:23 AM CEST, Luca Weiss wrote: > On Wed Jun 17, 2026 at 12:05 PM CEST, Konrad Dybcio wrote: >> On 5/22/26 4:46 PM, Luca Weiss wrote: >>> Due to initial kodiak/sc7280 bringup being done for Chrome platforms, >>> some Chrome-specific bits still remain in kodiak.dtsi, like the clocks >>> and power-domains for the LPASS RX/TX/WSA/VA macros. >>> >>> Move them to sc7280-chrome-common.dtsi and put Elite (q6afecc) >>> equivalents in its place. The qcs6490-audioreach.dtsi file can also drop >>> deletion of power-domains properties then. >>> >>> This follows previous commits moving Chrome-specific configuration to >>> the correct file, leaving kodiak.dtsi for Elite and >>> qcs6490-audioreach.dtsi for AudioReach. >>> >>> No functional change intended. The clock-output-names property will now >>> exist for both Chrome and AudioReach devices but this shouldn't have any >>> relevant effect. And WSA macro clocks weren't added to Chrome because I >>> don't believe this would've ever worked given it already referenced >>> q6afecc and the nodes were originally added during AudioReach bringup. >> >> I think it's better to keep them, if only to make sure that the result >> of dtx_diff isn't outside the expectation of a commit that claims to >> only reshuffle data for these platforms > > I documented this in the commit message for this purpose. > > But I'd argue not putting (likely incorrect) wsa_macro overrides there > is the better thing to do. Probably somebody should've taken care of the > Chrome platforms when adding the wsa nodes in the first place.
Is that okay, or do you want me to change this? I'm still of the opinion that adding a very-likely-broken WSA macro to chrome is not great. Anything else to note? R-b would be nice :) Regards Luca > >> >> It looks OK as-is for Elite and Audioreach platforms (for the record, I >> checked rb3gen2 and FP5) > > Thanks! > > Regards > Luca
