[PATCH] net: ethernet: remove unneeded dependency of mvneta and update help text
Ezequiel Garcia
ezequiel.garcia at free-electrons.com
Tue Feb 18 12:23:22 EST 2014
On Tue, Feb 18, 2014 at 04:51:28PM +0100, Thomas Petazzoni wrote:
> On Tue, 18 Feb 2014 12:45:12 -0300, Ezequiel Garcia wrote:
>
> > > At the very end of the clean up, when even Orion5x support will be
> > > merged in mach-mvebu/, then we can certainly replace these dependencies
> > > by a "depends on ARCH_MVEBU". But for the time being, PLAT_ORION seems
> > > like the right common denominator for all these platforms.
> > >
> >
> > Last time we talked about this with Sebastian and Andrew it was decided
> > that the right choice is:
> >
> > MACH_KIRKWOOD || MACH_DOVE || MACH_ARMADA_370_XP
>
> And why not Orion5x and MV78xx0 ?
>
Ouch, I confused s/MARCH/ARCH. What I meant to say is that instead of
PLAT_ORION, it was agreed to use:
ARCH_ORION5X || ARCH_KIRKWOOD || ARCH_DOVE || ARCH_MVEBU
See here for the previous discussion:
http://www.spinics.net/lists/devicetree/msg19091.html
We discussed the issue on its own thread:
http://www.spinics.net/lists/devicetree/msg19159.html
> >
> > Which would become MACH_MVEBU.
> >
> > Of course, this is near the nitpick boundary, so AFAIC you can leave
> > PLAT_ORION as in v2, if you feel like.
>
> As I suggested previously, PLAT_ORION is what *today* controls the
> visibility of all Marvell EBU drivers. Please grep for PLAT_ORION in
> your kernel tree.
Again, it has been agreed that those are all wrong and should all
be replaced by proper ARCH_whatever. Then, we'll probably be able to
stop selecting PLAT_ORION from ARCH_MVEBU.
> So why on earth would we invent something completely
> different for mvneta?
>
I don't have a strong opinion, it just feels wrong to have a different
rule each time. If you look at the watchdog patches, you'll notice we've
changed it to depend on ARCH_whatever.
So now you propose to go with PLAT_ORION. I'm fine with either of them;
but I think we should decide between one of them and stick to it, instead
of each of us having its own rule.
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
More information about the linux-arm-kernel
mailing list