On Tue, Mar 29, 2022 at 03:20:18PM +0200, Krzysztof Kozlowski wrote: > On 28/03/2022 02:09, Ansuel Smith wrote: > > Hi, > > as the title say, the intention of this ""series"" is to finally categorize > > the ARM dts directory in subdirectory for each oem. > > > > The main reason for this is that it became unpractical to handle 2600 > > dts files and try to even understand/edit/check the situation for a > > specific target. > > > > In arm64 we already have this kind of separation and I honestly think > > that this was never proposed for ARM due to the fact that there are > > 2600+ files to sort and the fact that it will be a mess to merge this > > entirely but IMHO with a little bit of effort we can finally solve this > > problem and have a well organized directory just like arm64. > > > > Some prerequisite on how this work was done: > > - This comes entirely from a python script created by me for the task. > > linked here [1] > > - I had to manually categorize all the different arch in the makefile > > based on the oem. I searched every arch on the internet trying to > > understand the correct oem. I hope they are correct but I would love > > some comments about them. > > - This current ""series"" is all squashed in one big commit to better > > receive comments for this. The final version ideally would have all > > changes in separate commits. The script can already do this, it's just > > commented. > > > > Here is a list of some discoveries while doing all the sorting. > > These are totally additional reason why we need this. > > > > While creating the script I discovered some funny things: > > - We have orphan dts! There are dts that are never compiled and are > > there just for reference. We would never have noticed this without this > > change and probably nobody noticed it. They are currently all listed > > in the python script. > > - We have dtsi shared across different oem. My current solution for them > > is: NOT SORT THEM and leave them in the generic directory and create a > > link in each oem dts that points to these dtsi. This is to try in > > every way possible to skip any additional changes to the dts. > > Current dtsi that suffers from this are only 3. (listed in the script) > > - arm64 dts and dtsi reference ARM dts. Obviously this change would cause > > broken include for these special dtsi. The script creates a dependency > > table of the entire arm64 directory and fix every broken dependency > > (hoping they all use a sane include logic... regex is used to parse > > all the different dependency) > > > > So in short the script does the following steps: > > 1. Enumerate all the action to do... (dts to move, scan dependency for > > the dts...) > > 2. Generate the arm64 dependency > > 3. Creates the Makefile > > 4. Generate the Makefiles for the current oem > > 5. Move all the related dts and dtsi for the current oem > > 6. Check broken dependency and fix them by editing the dts and writing > > the correct include (or fix any symbolic link) > > > > This is an output that describes all the things done by the script [2] > > > > I really hope I didn't commit any logic mistake in the script but most > > of the work should be done. > > > > +Cc Arnd and Olof, > > Ansuel, > Thanks for you patch. Please cc the SoC maintainers in such submissions. > It seems that you got some quite nice discussion, but still the core > folks are not Cced, so no one would be able to take your patch... > I had some problem with gmail and sending mail too much users. I put Rob and You and all the various list to try to workaround the "gmail spam protection" > I am pretty sure we were discussing such split idea in the past and it > did not get traction, but I cannot recall the exact discussion. > I think the main issue here is how to handle bot and how problematic is to merge this. As written in the cover letter the final version of this should be a big series of 50+ patch with every commit specific to each oem. In theory we should be able to merge the different oem separately and try to at least start the categorization. Another idea I got to at least have a "migration path" is to convert every dts in the dts/ directory to a symbolic link that target the dts in the correct oem. But I assume that would fix only part of the problem and git am will still be problematic. > To me the idea is good but will cause huge `git am` conflicts. > Cherry-picks, backports and merges should nicely detect path renames, > but git am (and b4 am) I think cannot. > I know but we should really consider this kind of change. The current state of the dts/ directory is embarassing and keeping it that way cause only more problems and makes this even more difficult. Hope we find a solution and fix this for good! > Best regards, > Krzysztof -- Ansuel
