21:44 <Marijn[m]> bamse: Are you available to talk about clocks, parent clocks, firmware and backwards compability?

21:44 <Marijn[m]> sboyd: ^ might want to chime in as well

21:47 <Marijn[m]> bamse: The thing is that all qcom platforms (phones) I'm currently working on use appended DTBs, and we always keep them in sync with the kernel by simply building and concatenating both in our flash scrips. I'm curious if that's the case for most other platforms, and if it is otherwise worth to maintain backwards compatibility by keeping transient "xo" clocks in gcc (the word "transient" isn't really fitting anymore) and keeping fallbacks

21:47 <Marijn[m]> to global clock names in place. sboyd already suggested that, if desired and mentioned explicitly in patchsets, we could break newer kernels with older firmware (DT) intentionally in favour of having a cleaner system in the end.

21:50 <Marijn[m]> bamse: I currently have the same cleanup you did to sdm660 sitting for msm8998 ready to be sent (might have noticed that we're sending more patches around that SoC 😉) but I want to get this cleared up to make a decision on whether to keep the "xo" clock and add `.name` fallbacks, before sending. Same questions apply for the DSI PLL parent-clock fixes.