From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] net: ethernet: remove unneeded dependency of mvneta and update help text
Date: Tue, 18 Feb 2014 15:10:27 +0100 [thread overview]
Message-ID: <20140218151027.710ab2f3@skate> (raw)
In-Reply-To: <20140218135809.GD17984@lunn.ch>
Dear Andrew Lunn,
On Tue, 18 Feb 2014 14:58:09 +0100, Andrew Lunn wrote:
> PLAT_ORION is a bit of an odd thing now.
>
> For me, PLAT_ORION means arch/arm/plat-orion.
No, it is PLAT_ORION_LEGACY which means arch/arm/plat-orion.
> But as far as i know, 370/XP does not actually use anything from
> arch/arm/plat-orion. When kirkwood moves into mach-mvebu, it also will
> not use any code from it, and i suspect dove is the same.
Interestingly, we have -I$(srctree)/arch/arm/plat-orion/include in
mach-mvebu/Makefile. Might be something to revisit later on.
> So maybe in a few cycles, when only mach-orion5x is left, we can merge
> arch/arm/plat-orion into arch/arm/mach-orion5x and PLAT_ORION goes
> away?
We also have mach-mv78xx0 to worry about, unless we decide to remove
support for it entirely. And even if plat-orion is merged into
mach-orion5x, we will keep PLAT_ORION as a way to indicate that the
platform needs to use a certain number of drivers (see below).
> Or do we want to define that PLAT_ORION means any system which can
> make use of mvebu drivers?
This is what it means today. The MV_XOR driver is under PLAT_ORION, the
gpio driver is under PLAT_ORION, the Device Bus driver is under
PLAT_ORION, the I2C driver is under PLAT_ORION, the pinctrl driver as
well, and so on and so on.
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.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Jason Cooper <jason@lakedaemon.net>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org,
Gregory Clement <gregory.clement@free-electrons.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] net: ethernet: remove unneeded dependency of mvneta and update help text
Date: Tue, 18 Feb 2014 15:10:27 +0100 [thread overview]
Message-ID: <20140218151027.710ab2f3@skate> (raw)
In-Reply-To: <20140218135809.GD17984@lunn.ch>
Dear Andrew Lunn,
On Tue, 18 Feb 2014 14:58:09 +0100, Andrew Lunn wrote:
> PLAT_ORION is a bit of an odd thing now.
>
> For me, PLAT_ORION means arch/arm/plat-orion.
No, it is PLAT_ORION_LEGACY which means arch/arm/plat-orion.
> But as far as i know, 370/XP does not actually use anything from
> arch/arm/plat-orion. When kirkwood moves into mach-mvebu, it also will
> not use any code from it, and i suspect dove is the same.
Interestingly, we have -I$(srctree)/arch/arm/plat-orion/include in
mach-mvebu/Makefile. Might be something to revisit later on.
> So maybe in a few cycles, when only mach-orion5x is left, we can merge
> arch/arm/plat-orion into arch/arm/mach-orion5x and PLAT_ORION goes
> away?
We also have mach-mv78xx0 to worry about, unless we decide to remove
support for it entirely. And even if plat-orion is merged into
mach-orion5x, we will keep PLAT_ORION as a way to indicate that the
platform needs to use a certain number of drivers (see below).
> Or do we want to define that PLAT_ORION means any system which can
> make use of mvebu drivers?
This is what it means today. The MV_XOR driver is under PLAT_ORION, the
gpio driver is under PLAT_ORION, the Device Bus driver is under
PLAT_ORION, the I2C driver is under PLAT_ORION, the pinctrl driver as
well, and so on and so on.
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.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2014-02-18 14:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-18 10:29 [PATCH] net: ethernet: remove unneeded dependency of mvneta and update help text Thomas Petazzoni
2014-02-18 10:29 ` Thomas Petazzoni
2014-02-18 12:29 ` Jason Cooper
2014-02-18 12:29 ` Jason Cooper
2014-02-18 12:45 ` Thomas Petazzoni
2014-02-18 12:45 ` Thomas Petazzoni
2014-02-18 12:52 ` Jason Cooper
2014-02-18 12:52 ` Jason Cooper
2014-02-18 13:13 ` Thomas Petazzoni
2014-02-18 13:13 ` Thomas Petazzoni
2014-02-18 13:58 ` Andrew Lunn
2014-02-18 13:58 ` Andrew Lunn
2014-02-18 14:10 ` Thomas Petazzoni [this message]
2014-02-18 14:10 ` Thomas Petazzoni
2014-02-18 15:45 ` Ezequiel Garcia
2014-02-18 15:45 ` Ezequiel Garcia
2014-02-18 15:51 ` Thomas Petazzoni
2014-02-18 15:51 ` Thomas Petazzoni
2014-02-18 17:23 ` Ezequiel Garcia
2014-02-18 17:23 ` Ezequiel Garcia
2014-02-19 2:10 ` Jisheng Zhang
2014-02-19 2:10 ` Jisheng Zhang
2014-02-19 8:08 ` Thomas Petazzoni
2014-02-19 8:08 ` Thomas Petazzoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140218151027.710ab2f3@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.