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,