Dear Albert ARIBAUD, In message <4aebff60.90...@free.fr> you wrote: > > Several kirkwood drivers could actually be reused almost as-is and > should thus be shared between both SoC families. For instance, > kirkwood_egiga.c and ehci-kirkwood.c would only differ by the number of > ports and kirkwood_i2c.c could be reused as-is. > > However, these drivers have hard-coded numbers of ports, and 'hard' > references to 'kirkwood.h' for their register definitions. Making them > cross-SoC would require moving the numbers of ports to some SoC-specific > header file, and that this header file *not* be named after a specific SoC.
... or to include the right SoC-specific header(s) only. > Instead, I have thought of replacing the #include "kirkwood.h" with a > #include "soc.h", where soc.h would exist in both SoC's header files "soc.h" is eventually a too generic name. > include/asm-arm/arch-kirkwood and include/asm-arm/arch-orion5x. This > soc.h file would either include the specific soc header file (kirkwood.h > or orion5x.h) or, better yet, be a symlink to it, or better again, > replace it. Please don't use symlinks. > This could be done in a two-step approach, each step being one commit. > > 1) introduce "soc.h" by: > > - 1a) renaming, symlinking or including kirkwood.h into soc.h and > changing kirkwood drivers that #include "kirkwood.h" accordingly; > > - 1b) turning all kirkwood-specific namings in these kirkwood drivers > into marvell-non-soc-specific ones (remove "KW_" prefixes and such). > > (steps 1a and 1b are independent) > We do things like #if defined(CONFIG_8xx) #include <asm/8xx_immap.h> ... #elif defined(CONFIG_5xx) #include <asm/5xx_immap.h> #elif defined(CONFIG_MPC5xxx) #include <mpc5xxx.h> #elif defined(CONFIG_MPC512X) #include <asm/immap_512x.h> #elif defined(CONFIG_MPC8220) #include <asm/immap_8220.h> ... even in pretty central files like "include/common.h". I don't want to suggest that this is the most beautiful solution, though. > 2) add orion5x support with its own "soc.h" file. > > Would this approach be clean enough to be considered for inclusion in > mainline? Yes, except for the "soc.h" name. And no links, please. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Obviously, a major malfunction has occurred." -- Steve Nesbitt, voice of Mission Control, January 28, 1986, as the shuttle Challenger exploded within view of the grandstands. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot