Dear Albert

-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@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.