[PATCH] arm: Add basic support for new Marvell Armada SoC family

On Wed, May 16, 2012 at 04:20:36PM -0400, Nicolas Pitre wrote:

On Wed, 16 May 2012, Arnd Bergmann wrote:

quoted

On Wednesday 16 May 2012, Nicolas Pitre wrote:

quoted

quoted

AFAICT, those are shared between most of those socs, and I would not want
to change the code in them to the new name.

Why not?  Module aliases can be used if that is a concern.

quoted

If we change the directory
name to something completely different, it no longer matches the driver
names.

I wouldn't consider this as a major concern.  For example, the ethernet 
driver that all those SOCs use is not called "orion".

It's not a big thing, I just feel that leaving the drivers alone makes
it a bit easier to port patches between kernel versions.

Sure.  My point is that we can rename the SOC directory and leave 
drivers alone if we wish to minimize churn.  Drivers can be renamed at a 
later time if that is seen as useful.

quoted

Another argument
for orion is that it's nicer to read as a function name prefix than
mrvl_ebu_* as you suggested. The main counterargument to keeping orion_
as I understand it is that it's actually only the name for the oldest
members of this family, right? This is a good point, but we also have
a lot of other cases in the kernel where code is named after the first
thing that used it, e.g. arch/x86 was called arch/i386 for a long time
and we still have tons of references to that.

Indeed.  "sa1100" is another example of that and I didn't want to rename 
it to sa11x0 at the time.

But in the sa1100 or i386 cases, the alternatives are close enough not 
to cause too much confusion.

In this case, we have wildly different names referring to the same chip 
family, and "orion" is far from hinting that it also constitute the 
support for Kirkwood, Dove or (some not all) Armadas, unless you are 
familiar with some legacy Marvell products.  This is why in this case I 
think that a directory name change might be appropriate, _especially_ if 
we're going to cause churn by moving things around already.

I agree that mrvl_ebu_* is not pretty.  This could be mv_ebu_* or 
mvebu_*.  Unless someone has another logical identifier to suggest which 
would capture all that family of SOCs that came out of EBU in Marvell of 
course.

I prefer mvebu_* ...  nice and concise.

thx,

Jason.