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

[Albert ARIBAUD <albert.aribaud@free.fr>]

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).

 > 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.

 > Regards.. Prafulla . .

Amicalement,
-- 
Albert.