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

[Prafulla Wadaskar]

Dear Albert 

> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr] 
> Sent: Monday, November 02, 2009 5:46 PM
> To: Prafulla Wadaskar
> Subject: Re: [U-Boot] Best way of making some drivers common 
> across kirkwood and orion5x SoCs?
> 
> Prafulla Wadaskar a écrit :
> > 
> >> Still, the drivers would be full of 'KWxxx" and "kwxxx" symbols of
> >> which many are not kirkwood-specific actually.
> > 
> > Any way, those are not even orion specific nor Marvell specific. 
> > Those are related to the functionality supported by SOCs that may be
> > customized by each SOC
> > 
> >> In order for these drivers to compile with an orion5x SoC, I would
> >> have to adopt kirkwood names in the
> > 
> > What harm in this?
> 
> I would say it harms maintenability and reuseability of the code. If
> those drivers are neither kirkwood- nor even 
> marvell-specific, then they
> should not lead readers to believe they are, otherwise people 
> might not
> realize they can ruse these drivers in their own SoCs.
> 
> >> orion5x code, which I don't like as much as I would like fixing the
> >> 
> > If you see kernel code even there you can see kirkwood call from
> > Orion drivers and vice versa.
> > 
> >> symbols to make them marvell-, not kirkwood-, specific.
> > 
> > This will not solve the root problem, what about some non 
> marvell SoC
> > have same h/w and want to reuse the code? Do we again change the
> > suffixes? (kirkwood re-used external serial driver adopting external
> > definitions).
> 
> Point valid and taken--see my suggestion below.
> 
> > I suggest here to adopt kw symbols in Orion. This would 
> make it clear
> > for anybody that kirkwood code is reused by orion. With 
> this kirkwood
> > drives will be untouched.
> 
> This does not solve the root problem any better than switching to 
> Marvell prefixes, as you rightly point out. I thus suggest 
> removing any 
> Marvell, Kirkwood or Orion prefixes from symbols in these drivers 
> altogether. For instance, egiga symbols would take EGIGA_ as 
> a prefix. 
> Then each SoC (kirkwood, orion5x, any other) header file 
> would provide 
> adequate definitions (#define EGIGA_xxxx yyyy).

I understands your concerns-
1. For SOC support Orion should be implemented similar to Kirkwood (you agreed on this)
2. For common drivers for (ex: kirkwood_egiga.c) the common code must be abstracted to egiga_core.c and architecture specific code must be supported through kirkwood_egiga.c/h and orion_egiga.c/h, this way it would make it more clean and structured.

> 
> > While doing this reuse activity, if we find something blocking,
> > certainly we should address that, but let's avoid changing identity
> > of drivers.
> 
> I personally believe that having the Orion5x SoC dependent of the 
> kirkwood one is blocking enough from a design standpoint.

What is your opinion with #2 suggestion?

Regards..
Prafulla . .

> 
> > Regards.. Prafulla . .
> 
> Amicalement,
> -- 
> Albert.
>