Hi, On Thu, 6 Oct 2022 at 11:21, Johan Hovold <johan@xxxxxxxxxx> wrote: > > On Thu, Sep 22, 2022 at 04:32:00PM +0200, Krzysztof Kozlowski wrote: > > Hi everyone, > > > > Quite a lot of people are working on Qualcomm DT bindings conversion > > (TXT->YAML) and fixups to Qualcomm DTS. We track a bit of this effort > > internally in Linaro, but that has many shortcomings and we would like > > to track it rather community-wide with the support and contributions > > from the community. > > > > What to track: > > 1. Which bindings to convert to YAML, > > 2. Missing compatibles (either entirely or because of missing conversion), > > 3. `dt_binding_check` warnings (usually connected with 1-2), > > 4. `dtbs_check` warnings. > > > > Rob's bot gives us daily output for 1-4, but how can we track current > > efforts to avoid duplication of work? Also it would allow people to find > > tasks for them to get contributions to Linux kernel :). Is anyone in > > community interested in tracking it together, in a public way? > > Is this a real problem that needs fixing? I mean how often does it > happen that people submit the same YAML conversion for example? Since it > doesn't take that long to do a conversion, I'm not sure what tracking > this on some webpage buys us. It's better to just search lore before > starting a new conversion. Or search the linux-next tree to see what's > still pending. As Krzysztof wrote, fixing a warning/adding a new platform is usually not a big deal. However converting old txt bindings usually results in a significant amount of work. Fixing YAML and dtsi at the same time can take a long time, especially for obscure cases like apq8084 or old ipq boards. > > Similarly for the other points above, as it doesn't take very long to > add a missing compatible or fix a warning it seems a bit excessive to > try to track this manually. > > Perhaps a list of pending conversions or missing compatibles could be > useful for someone who's short on work, but it's bound to get outdated > pretty quickly. I'd suggest having a list of `qcom-legacy' tasks: outdated DT bindings (both txt and yaml), drivers using system clock list (rather than DT bindings). DT files pending conversion to labels. msm8974 interconnect driver. hsuart aliases. You name it. This can be as simple as several gitlab issues, one per each topic. At the very least this would allow us to assess legacy bits and pieces. Note: for me this is close to another topic that was discussed several times, but for which we never reached a conclusion. A matrix of supported per-SoC features. > > > If so, where? > > A. elinux.org (needs some formatting when pasting the output from tools) > > B. gitlab pages/wiki (maybe scripts could parse tools and create the page?) > > C. gitlab dedicated repo - some text file > > D. Linux kernel TODO file (might be difficult to keep updated) > > E. kernel.org wiki (requires LF accounts, AFAIK, a bit pain to edit; I > > have it for Exynos but I don't find it usable - > > https://exynos.wiki.kernel.org/todo_tasks) > > > > I am leaning towards Gitlab pages because they could be quite automated > > - with CI or with scripts. > > > > The point would be to list all of tasks (1-4 from the first list), keep > > it updated with new results, pick/assign tasks and mark as done. > > I don't really see the need for more process here, sorry. > > If I'm working on support for a new platform and the DT checker warnings > gets too noisy I may pick some of the low hanging fruit. In the odd > chance that someone beats me to it, it's not the end of the world. I hope that we can finally land patches to support per-file check. Then fixing warnings for a new platform would be very easy. Even today you can run `make something.dtb CHECK_DTBS=y` and get all your warnings (if the processed schema is up to date). However Krzysztof's point is about old platforms, rather than new ones. -- With best wishes Dmitry
