It looks as a good idea, although possibly an intermediate directory would be desireable not to clutter arch/mips too much. E.g:
arch/mips/platforms/platform1/... /platform2/...
From my experience with other architectures, fewer intermediate directories are often useful, for example:
arch/mips/platforms/board_and_chip_files
allows a maximum amount of code sharing and minimal duplication. When you have lots of lower level directories, you often have many identical files in them that should be shared, but are not, causing support/update challenges. For example:
arch/mips/platforms/mfg_board_common.[ch] arch/mips/platforms/mfg_board_type1.[ch] arch/mips/platforms/mfg_board_type2.[ch]
keeps all manufacturer shared code in one place, and the board files could be quite small. I have the specific case right now with a board vendor that has about six similar boards, all in separate directories like this:
arch/mips/au1000/board1/file.c arch/mips/au1000/board2/file.c arch/mips/au1000/board3/file.c
where the code is all identical in those files. My first move is going to be consolidation of all of the "board" directories into a single "manufacturer" directory just to eliminate the overhead of keeping all of these files consistent on updates. Then, I'm just going to prefix the board type to the unique file names. I find this much easier to maintain and to share code. Common sense file names using a standard manufacturer/board name prefix makes the files just as easy to identify as separate directories.
It would be nice to see the defconfig files in their own directory, that would be the single most useful way to eliminate some clutter :-)
Thanks.
-- Dan
