[U-Boot] Best way of making some drivers common across kirkwood and orion5x SoCs?

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4AEBFF60.90902 at 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: wd at 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.