* [PATCH V3 0/3] Add clock framework for armada 370/XP
From: Gregory CLEMENT @ 2012-10-21 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017153925.GR20922@titan.lakedaemon.net>
On 10/17/2012 05:39 PM, Jason Cooper wrote:
> Mike,
>
> On Mon, Oct 15, 2012 at 02:18:16PM +0200, Gregory CLEMENT wrote:
>> Hello Mike,
>>
>> The v3.7-rc1 was released yesterday. So here it is the updated version
>> of my patch set. The rebase was flawless. An I have just fixed a typo
>> in the device tree and warnings from checkpatch. I built and test it
>> for the Armada 370 and Armada XP evaluation board.
>>
>> The purpose of this patch set is to add support for clock framework
>> for Armada 370 and Armada XP SoCs. All the support is done under the
>> directory drivers/clk/mvebu/ as the support for other mvebu SoCs was
>> in mind during the writing of the code.
>>
>> Two kinds of clocks are added:
>>
>> - The CPU clocks are only for Armada XP (which is multi-core)
>>
>> - The core clocks are clocks which have their rate fixed during
>> reset.
>>
>> Many thanks to Thomas Petazzoni and Sebastian Hesselbarth for their
>> review and feedback. The device tree bindings were really improved
>> with the advices of Sebastian.
>>
>> Changelog:
>> V2 -> V3:
>> - Rebased on top of v3.7-rc1
>> - Fixed a typo in device trees
>> - Fixed warning from checkpatch
>>
>> V1 -> V2:
>>
>> - Improved the spelling and the wording of the documentation and the
>> 1st commit log
>> - Removed the "end_of_list" name which are unused here.
>> - Fix the cpu clock by using of_clk_src_onecell_get in the same way it
>> was used for the core clocks
>>
>> Regards,
>>
>>
>> Gregory CLEMENT (3):
>> clk: mvebu: add armada-370-xp specific clocks
>> clk: armada-370-xp: add support for clock framework
>> clocksource: time-armada-370-xp converted to clk framework
>>
>> .../devicetree/bindings/clock/mvebu-core-clock.txt | 40 +++
>> .../devicetree/bindings/clock/mvebu-cpu-clock.txt | 21 ++
>> arch/arm/boot/dts/armada-370-db.dts | 4 -
>> arch/arm/boot/dts/armada-370-xp.dtsi | 1 +
>> arch/arm/boot/dts/armada-370.dtsi | 12 +
>> arch/arm/boot/dts/armada-xp.dtsi | 48 +++
>> arch/arm/mach-mvebu/Kconfig | 5 +
>> arch/arm/mach-mvebu/armada-370-xp.c | 8 +-
>> arch/arm/mach-mvebu/common.h | 1 +
>> drivers/clk/Makefile | 1 +
>> drivers/clk/mvebu/Makefile | 2 +
>> drivers/clk/mvebu/clk-core.c | 312 ++++++++++++++++++++
>> drivers/clk/mvebu/clk-core.h | 19 ++
>> drivers/clk/mvebu/clk-cpu.c | 155 ++++++++++
>> drivers/clk/mvebu/clk-cpu.h | 19 ++
>> drivers/clk/mvebu/clk.c | 36 +++
>> drivers/clocksource/time-armada-370-xp.c | 11 +-
>> 17 files changed, 685 insertions(+), 10 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
>> create mode 100644 Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
>> create mode 100644 drivers/clk/mvebu/Makefile
>> create mode 100644 drivers/clk/mvebu/clk-core.c
>> create mode 100644 drivers/clk/mvebu/clk-core.h
>> create mode 100644 drivers/clk/mvebu/clk-cpu.c
>> create mode 100644 drivers/clk/mvebu/clk-cpu.h
>> create mode 100644 drivers/clk/mvebu/clk.c
>
> Would it be okay if we took this through the mvebu tree? It looks like
> the only potential merge conflict we would have would be in
> drivers/clk/Makefile. It would make dependency tracking easier.
>
It will also be easier for me if it was possible, because I have
patch series awaiting which will depend on the support of the
clock framework for mvebu.
> Otherwise is fine as well, just let me know which you prefer.
>
> Assuming, of course, everything looks good to you.
>
> thx,
>
> Jason.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Mohammed, Afzal @ 2012-10-21 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121021073551.GA4735@netboy.at.omicron.at>
Hi Richard,
* Richard Cochran, October 21, 2012 1:05 PM:
> People keep saying, the beaglebone works fine with v3.7-rc1, but it
> isn't true. Now v3.7-rc2 is out, and the gpmc issue still has not been
> fixed, and no one is doing anything about it either.
A fix to resolve the gpmc issue has been merged recently, so I am
expecting beagle bone to boot on -rc2 (I don't have hardware to test,
on vacation now), can you please try with -rc2.
Note: Sending via exchange, hope this is readable.
Regards
Afzal
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Richard Cochran @ 2012-10-21 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA012D8@DBDE01.ent.ti.com>
On Sun, Oct 21, 2012 at 12:29:26PM +0000, Mohammed, Afzal wrote:
> Hi Richard,
>
> * Richard Cochran, October 21, 2012 1:05 PM:
>
> > People keep saying, the beaglebone works fine with v3.7-rc1, but it
> > isn't true. Now v3.7-rc2 is out, and the gpmc issue still has not been
> > fixed, and no one is doing anything about it either.
>
> A fix to resolve the gpmc issue has been merged recently, so I am
> expecting beagle bone to boot on -rc2 (I don't have hardware to test,
> on vacation now), can you please try with -rc2.
I am happy to report that v3.7-rc2 boots via the modern DT method,
using Paul's am33xx_only config and U-Boot 2012.10-rc1-00148-g4668a08.
Thanks, and have a nice vacation,
Richard
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Matt Porter @ 2012-10-21 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210201856020.27264@utopia.booyaka.com>
On Sat, Oct 20, 2012 at 06:58:10PM +0000, Paul Walmsley wrote:
> On Sat, 20 Oct 2012, Richard Cochran wrote:
>
> > On Sat, Oct 20, 2012 at 06:12:35PM +0000, Paul Walmsley wrote:
> > > Just tried omap2plus_defconfig here and the board didn't boot, confirming
> > > your result. Will add a section to the testlog README.txt about that.
> > >
> > > > > In terms of differences from your setup, looks like we have different
> > > > > X-Loader and u-boot; it wouldn't surprise me if we have different kernel
> > > > > configs too.
> >
> > I tried both omap2plus_defconfig and your am33xx_only config, and
> > neither one work with my (recent) u-boot version.
>
> Just sent you the MLO and u-boot.img from here via private E-mail. Those
> were the files that came with the BeagleBone SD card here.
>
> TI also has a u-boot tree for the AM33xx; might be worth trying:
>
> git://arago-project.org/git/projects/u-boot-am33x.git
Use of the vendor tree should be discouraged. The best thing to use
is current ToT U-Boot mainline or the v2012.10 stable U-Boot release.
X-Loader is deprecated by U-Boot SPL.
-Matt
^ permalink raw reply
* [PATCH 2/2] ARM: kirkwood: use gpio-fan DT binding on lsxl
From: Michael Walle @ 2012-10-21 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121021065552.GH21046@lunn.ch>
Am Sonntag 21 Oktober 2012, 08:55:52 schrieb Andrew Lunn:
> On Sun, Oct 21, 2012 at 01:34:54AM +0200, Michael Walle wrote:
> > Remove board specific gpio-fan driver registration. Moved into device
> > tree.
> >
> > Signed-off-by: Michael Walle <michael@walle.cc>
> > ---
> >
> > arch/arm/boot/dts/kirkwood-lsxl.dtsi | 11 ++++++++
> > arch/arm/mach-kirkwood/board-lsxl.c | 47
> > ---------------------------------- 2 files changed, 11 insertions(+),
> > 47 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
> > b/arch/arm/boot/dts/kirkwood-lsxl.dtsi index 8fea375..798e60e 100644
> > --- a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
> > +++ b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
> > @@ -94,4 +94,15 @@
> >
> > gpios = <&gpio1 16 1>;
> >
> > };
> >
> > };
> >
> > +
> > + gpio_fan {
> > + compatible = "gpio-fan";
> > + gpios = <&gpio0 19 1
> > + &gpio0 18 1>;
> > + gpio-fan,speed-map = <0 3
> > + 1500 2
> > + 3250 1
> > + 5000 0>;
> > + alarm-gpios = <&gpio1 8 0>;
> > + };
> >
> > };
> >
> > diff --git a/arch/arm/mach-kirkwood/board-lsxl.c
> > b/arch/arm/mach-kirkwood/board-lsxl.c index 64e5cc6..7e18cad 100644
> > --- a/arch/arm/mach-kirkwood/board-lsxl.c
> > +++ b/arch/arm/mach-kirkwood/board-lsxl.c
> > @@ -16,7 +16,6 @@
> >
> > #include <linux/platform_device.h>
> > #include <linux/mv643xx_eth.h>
> > #include <linux/gpio.h>
> >
> > -#include <linux/gpio-fan.h>
> >
> > #include "common.h"
> > #include "mpp.h"
>
> Hi Michael
>
> You might also be able to remove platform_device.h.
Mh, pm_power_off, although defined in linux/pm.h, is somehow pulled with this
include. So either we leave it that way (looking at other boards only a few
has included pm.h) or i'll post a third patch which replaces that include.
--
Michael
^ permalink raw reply
* [PATCH 0/5] make cadence ethernet drivers build on any architecture
From: Joachim Eastwood @ 2012-10-21 14:23 UTC (permalink / raw)
To: linux-arm-kernel
This series makes the at91_ether and macb driver build-able on any architecture.
Patch 1 removes the HAVE_NET_MACB from the cadence Kconfig and this allow macb to be built on any architecture. The macb driver requires no other modifications.
Patch 3 moves a bootloader quirk for CSB337 from at91_ether into CSB337 board setup. This allow us to remove the last mach include and build this driver on any architecture. It also make it easier to share the address setup between at91_ether and macb.
Patch 4-5 removes the now unused HAVE_NET_MACB config symbol from AT91/AVR32 Kconfig.
Note that patch 3 is not tested on a real CSB337 board. I only tested it on an other AT91RM9200 board to verify the logic that reverses the address byte order works.
The next series will make the at91_ether driver use address setting and statistics from macb. There is also a clean up of print outs plus some comment/style fixes.
Joachim Eastwood (5):
net/cadence: get rid of HAVE_NET_MACB
net/at91_ether: select MACB in Kconfig
net/at91_ether: move eth addr quirk into csb337 board setup
ARM: AT91: Remove HAVE_NET_MACB
AVR32: Remove HAVE_NET_MACB
arch/arm/mach-at91/Kconfig | 4 ----
arch/arm/mach-at91/board-csb337.c | 35 +++++++++++++++++++++++++++++++
arch/avr32/Kconfig | 1 -
drivers/net/ethernet/cadence/Kconfig | 8 +------
drivers/net/ethernet/cadence/Makefile | 2 +-
drivers/net/ethernet/cadence/at91_ether.c | 26 ++++++-----------------
6 files changed, 43 insertions(+), 33 deletions(-)
--
1.7.12.4
^ permalink raw reply
* [PATCH 1/5] net/cadence: get rid of HAVE_NET_MACB
From: Joachim Eastwood @ 2012-10-21 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350829392-3812-1-git-send-email-manabian@gmail.com>
macb is a platform driver and there is nothing that prevents
this driver from being built on non-ARM/AVR32 platforms.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
drivers/net/ethernet/cadence/Kconfig | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index 57f78abe..5d1ea30 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -2,13 +2,9 @@
# Atmel device configuration
#
-config HAVE_NET_MACB
- bool
-
config NET_CADENCE
bool "Cadence devices"
default y
- depends on HAVE_NET_MACB || (ARM && ARCH_AT91RM9200)
---help---
If you have a network (Ethernet) card belonging to this class, say Y.
Make sure you know the name of your card. Read the Ethernet-HOWTO,
@@ -34,7 +30,6 @@ config ARM_AT91_ETHER
config MACB
tristate "Cadence MACB/GEM support"
- depends on HAVE_NET_MACB
select PHYLIB
---help---
The Cadence MACB ethernet interface is found on many Atmel AT32 and
--
1.7.12.4
^ permalink raw reply related
* [PATCH 2/5] net/at91_ether: select MACB in Kconfig
From: Joachim Eastwood @ 2012-10-21 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350829392-3812-1-git-send-email-manabian@gmail.com>
Now that HAVE_NET_MACB is gone let's just select MACB to
satisfy the dependecies in at91_ether.
PHYLIB will then by selected by MACB.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
drivers/net/ethernet/cadence/Kconfig | 2 +-
drivers/net/ethernet/cadence/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index 5d1ea30..f6d0956 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -23,7 +23,7 @@ config ARM_AT91_ETHER
tristate "AT91RM9200 Ethernet support"
depends on ARM && ARCH_AT91RM9200
select NET_CORE
- select PHYLIB
+ select MACB
---help---
If you wish to compile a kernel for the AT91RM9200 and enable
ethernet support, then you should always answer Y to this.
diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
index 798b1e0..9068b83 100644
--- a/drivers/net/ethernet/cadence/Makefile
+++ b/drivers/net/ethernet/cadence/Makefile
@@ -2,5 +2,5 @@
# Makefile for the Atmel network device drivers.
#
-obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o macb.o
+obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
obj-$(CONFIG_MACB) += macb.o
--
1.7.12.4
^ permalink raw reply related
* [PATCH 3/5] net/at91_ether: move eth addr quirk into csb337 board setup
From: Joachim Eastwood @ 2012-10-21 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350829392-3812-1-git-send-email-manabian@gmail.com>
Move Ethernet address byte order fix for csb337 into it's board
setup.
This will allow us to remove the last mach include from at91_ether
and also to share the address setup with the macb driver.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
arch/arm/mach-at91/board-csb337.c | 35 +++++++++++++++++++++++++++++++
drivers/net/ethernet/cadence/Kconfig | 1 -
drivers/net/ethernet/cadence/at91_ether.c | 26 ++++++-----------------
3 files changed, 41 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-at91/board-csb337.c b/arch/arm/mach-at91/board-csb337.c
index 3e37437..5522132 100644
--- a/arch/arm/mach-at91/board-csb337.c
+++ b/arch/arm/mach-at91/board-csb337.c
@@ -217,6 +217,40 @@ static struct gpio_led csb_leds[] = {
}
};
+/*
+ * MicroMonitor (uMon) on the CSB337 store the ethernet address in the
+ * wrong byte order (and continues to do so, for bug-compatibility).
+ */
+#define MACB_SA1B 0x0098
+#define MACB_SA1T 0x009c
+static void __init csb337_fix_eth_addr(void)
+{
+ void __iomem *emac;
+ u32 lo, hi, tmp;
+ int i;
+
+ emac = ioremap(AT91RM9200_BASE_EMAC, SZ_16K);
+ if (!emac) {
+ printk(KERN_ERR "csb337: unable to fixup Ethernet address\n");
+ return;
+ }
+
+ /* Fix byte order on all 4 address registers */
+ for (i = 0; i < 4; i++) {
+ lo = readl(emac + MACB_SA1B + i * 8);
+ hi = readl(emac + MACB_SA1T + i * 8);
+
+ tmp = (lo & 0xff) << 8 | (lo & 0xff00) >> 8;
+ writel(tmp, emac + MACB_SA1T + i * 8);
+
+ tmp = (hi & 0xff) << 8 | (hi & 0xff00) >> 8
+ | (lo & 0xff0000) << 8
+ | (lo & 0xff000000) >> 8;
+ writel(tmp, emac + MACB_SA1B + i * 8);
+ }
+
+ iounmap(emac);
+}
static void __init csb337_board_init(void)
{
@@ -225,6 +259,7 @@ static void __init csb337_board_init(void)
at91_register_uart(0, 0, 0);
at91_add_device_serial();
/* Ethernet */
+ csb337_fix_eth_addr();
at91_add_device_eth(&csb337_eth_data);
/* USB Host */
at91_add_device_usbh(&csb337_usbh_data);
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index f6d0956..40172d1 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -21,7 +21,6 @@ if NET_CADENCE
config ARM_AT91_ETHER
tristate "AT91RM9200 Ethernet support"
- depends on ARM && ARCH_AT91RM9200
select NET_CORE
select MACB
---help---
diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
index 375d272..5ed1a63 100644
--- a/drivers/net/ethernet/cadence/at91_ether.c
+++ b/drivers/net/ethernet/cadence/at91_ether.c
@@ -32,8 +32,6 @@
#include <linux/phy.h>
#include <linux/io.h>
-#include <asm/mach-types.h>
-
#include "macb.h"
#define DRV_NAME "at91_ether"
@@ -55,30 +53,18 @@
* U-Boot on the AT91RM9200-DK do not do this.
*
* - Likewise it must store the addresses in the correct byte order.
- * MicroMonitor (uMon) on the CSB337 does this incorrectly (and
- * continues to do so, for bug-compatibility).
*/
static short __init unpack_mac_address(struct net_device *dev, unsigned int hi, unsigned int lo)
{
char addr[6];
- if (machine_is_csb337()) {
- addr[5] = (lo & 0xff); /* The CSB337 bootloader stores the MAC the wrong-way around */
- addr[4] = (lo & 0xff00) >> 8;
- addr[3] = (lo & 0xff0000) >> 16;
- addr[2] = (lo & 0xff000000) >> 24;
- addr[1] = (hi & 0xff);
- addr[0] = (hi & 0xff00) >> 8;
- }
- else {
- addr[0] = (lo & 0xff);
- addr[1] = (lo & 0xff00) >> 8;
- addr[2] = (lo & 0xff0000) >> 16;
- addr[3] = (lo & 0xff000000) >> 24;
- addr[4] = (hi & 0xff);
- addr[5] = (hi & 0xff00) >> 8;
- }
+ addr[0] = (lo & 0xff);
+ addr[1] = (lo & 0xff00) >> 8;
+ addr[2] = (lo & 0xff0000) >> 16;
+ addr[3] = (lo & 0xff000000) >> 24;
+ addr[4] = (hi & 0xff);
+ addr[5] = (hi & 0xff00) >> 8;
if (is_valid_ether_addr(addr)) {
memcpy(dev->dev_addr, &addr, 6);
--
1.7.12.4
^ permalink raw reply related
* [PATCH 4/5] ARM: AT91: Remove HAVE_NET_MACB
From: Joachim Eastwood @ 2012-10-21 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350829392-3812-1-git-send-email-manabian@gmail.com>
HAVE_NET_MACB has already been removed from the driver itself
so removed it from mach Kconfig as well.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
arch/arm/mach-at91/Kconfig | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index d846b6e..72020fb 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -45,7 +45,6 @@ config SOC_AT91RM9200
config SOC_AT91SAM9260
bool "AT91SAM9260, AT91SAM9XE or AT91SAM9G20"
select HAVE_AT91_DBGU0
- select HAVE_NET_MACB
select SOC_AT91SAM9
help
Select this if you are using one of Atmel's AT91SAM9260, AT91SAM9XE
@@ -63,7 +62,6 @@ config SOC_AT91SAM9263
bool "AT91SAM9263"
select HAVE_AT91_DBGU1
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
select SOC_AT91SAM9
config SOC_AT91SAM9RL
@@ -76,7 +74,6 @@ config SOC_AT91SAM9G45
bool "AT91SAM9G45 or AT91SAM9M10 families"
select HAVE_AT91_DBGU1
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
select SOC_AT91SAM9
help
Select this if you are using one of Atmel's AT91SAM9G45 family SoC.
@@ -86,7 +83,6 @@ config SOC_AT91SAM9X5
bool "AT91SAM9x5 family"
select HAVE_AT91_DBGU0
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
select SOC_AT91SAM9
help
Select this if you are using one of Atmel's AT91SAM9x5 family SoC.
--
1.7.12.4
^ permalink raw reply related
* [PATCH 5/5] AVR32: Remove HAVE_NET_MACB
From: Joachim Eastwood @ 2012-10-21 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350829392-3812-1-git-send-email-manabian@gmail.com>
HAVE_NET_MACB has already been removed from the driver itself
so removed it from arch Kconfig as well.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
arch/avr32/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index 06e73bf..09f9fa8 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -80,7 +80,6 @@ config PLATFORM_AT32AP
select ARCH_REQUIRE_GPIOLIB
select GENERIC_ALLOCATOR
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
#
# CPU types
--
1.7.12.4
^ permalink raw reply related
* [PATCH v4 3/5] zynq: remove use of CLKDEV_LOOKUP
From: Josh Cartwright @ 2012-10-21 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351466765.git.josh.cartwright@ni.com>
The Zynq support in mainline does not (yet) make use of any of the
generic clk or clk lookup functionality. Remove what is upstream for
now, until the out-of-tree implementation is in suitable form for
merging.
An important side effect of this patch is that it allows the building of
a Zynq kernel without running into unresolved symbol problems:
drivers/built-in.o: In function `amba_get_enable_pclk':
clkdev.c:(.text+0x444): undefined reference to `clk_enable'
drivers/built-in.o: In function `amba_remove':
clkdev.c:(.text+0x488): undefined reference to `clk_disable'
drivers/built-in.o: In function `amba_probe':
clkdev.c:(.text+0x540): undefined reference to `clk_disable'
drivers/built-in.o: In function `amba_device_add':
clkdev.c:(.text+0x77c): undefined reference to `clk_disable'
drivers/built-in.o: In function `enable_clock':
clkdev.c:(.text+0x29738): undefined reference to `clk_enable'
drivers/built-in.o: In function `disable_clock':
clkdev.c:(.text+0x29778): undefined reference to `clk_disable'
drivers/built-in.o: In function `__pm_clk_remove':
clkdev.c:(.text+0x297f8): undefined reference to `clk_disable'
drivers/built-in.o: In function `pm_clk_suspend':
clkdev.c:(.text+0x29bc8): undefined reference to `clk_disable'
drivers/built-in.o: In function `pm_clk_resume':
clkdev.c:(.text+0x29c28): undefined reference to `clk_enable'
make[2]: *** [vmlinux] Error 1
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
In addition, eliminate Zynq's "use" of the versatile platform, as it is no longer
needed. As Nick Bowler points out:
For the record, I think this was introduced by commit 56a34b03ff427
("ARM: versatile: Make plat-versatile clock optional") which forgot to
select PLAT_VERSATILE_CLOCK on Zynq. This is not all that surprising,
because the fact that Zynq "uses" PLAT_VERSATILE is secretly hidden in
the Makefile.
Nevertheless, the only feature from versatile that Zynq needed was the
clock support, so this patch should *also* delete the secret use of
plat-versatile by removing this line from arch/arm/Makefile:
plat-$(CONFIG_ARCH_ZYNQ) += versatile
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
Cc: John Linn <john.linn@xilinx.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Michal Simek <michal.simek@xilinx.com>
---
arch/arm/Kconfig | 1 -
arch/arm/Makefile | 1 -
arch/arm/mach-zynq/common.c | 1 -
arch/arm/mach-zynq/include/mach/clkdev.h | 32 --------------------------------
4 files changed, 35 deletions(-)
delete mode 100644 arch/arm/mach-zynq/include/mach/clkdev.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ef6d059..3ab72e1 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -948,7 +948,6 @@ config ARCH_ZYNQ
bool "Xilinx Zynq ARM Cortex A9 Platform"
select ARM_AMBA
select ARM_GIC
- select CLKDEV_LOOKUP
select CPU_V7
select GENERIC_CLOCKEVENTS
select ICST
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 451757d..8dbab2d 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -197,7 +197,6 @@ machine-$(CONFIG_ARCH_ZYNQ) += zynq
# by CONFIG_* macro name.
plat-$(CONFIG_ARCH_OMAP) += omap
plat-$(CONFIG_ARCH_S3C64XX) += samsung
-plat-$(CONFIG_ARCH_ZYNQ) += versatile
plat-$(CONFIG_PLAT_IOP) += iop
plat-$(CONFIG_PLAT_NOMADIK) += nomadik
plat-$(CONFIG_PLAT_ORION) += orion
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 056091a..ba48f06 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -31,7 +31,6 @@
#include <asm/hardware/cache-l2x0.h>
#include <mach/zynq_soc.h>
-#include <mach/clkdev.h>
#include "common.h"
static struct of_device_id zynq_of_bus_ids[] __initdata = {
diff --git a/arch/arm/mach-zynq/include/mach/clkdev.h b/arch/arm/mach-zynq/include/mach/clkdev.h
deleted file mode 100644
index c6e73d8..0000000
--- a/arch/arm/mach-zynq/include/mach/clkdev.h
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * arch/arm/mach-zynq/include/mach/clkdev.h
- *
- * Copyright (C) 2011 Xilinx, Inc.
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#ifndef __MACH_CLKDEV_H__
-#define __MACH_CLKDEV_H__
-
-#include <plat/clock.h>
-
-struct clk {
- unsigned long rate;
- const struct clk_ops *ops;
- const struct icst_params *params;
- void __iomem *vcoreg;
-};
-
-#define __clk_get(clk) ({ 1; })
-#define __clk_put(clk) do { } while (0)
-
-#endif
--
1.8.0
^ permalink raw reply related
* [PATCH] ARM: EXYNOS: exynos4-dt: Set .smp field of machine descriptor
From: Tomasz Figa @ 2012-10-21 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350035378-31989-1-git-send-email-t.figa@samsung.com>
On Friday 12 of October 2012 11:49:38 Tomasz Figa wrote:
> This patch adds missing initializer of .smp field of machine descriptor
> of Exynos 4 DT machine.
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> ---
> arch/arm/mach-exynos/mach-exynos4-dt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
> b/arch/arm/mach-exynos/mach-exynos4-dt.c index 7222e3c..d6bdcfb 100644
> --- a/arch/arm/mach-exynos/mach-exynos4-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
> @@ -119,6 +119,7 @@ static char const *exynos4_dt_compat[] __initdata =
> {
>
> DT_MACHINE_START(EXYNOS4210_DT, "Samsung Exynos4 (Flattened Device
> Tree)") /* Maintainer: Thomas Abraham <thomas.abraham@linaro.org> */
> + .smp = smp_ops(exynos_smp_ops),
> .init_irq = exynos4_init_irq,
> .map_io = exynos4_dt_map_io,
> .handle_irq = gic_handle_irq,
Ping. I think this should be considered a fix.
Best regards,
Tomasz Figa
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Paul Walmsley @ 2012-10-21 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121021114446.GC6756@netboy.at.omicron.at>
On Sun, 21 Oct 2012, Richard Cochran wrote:
> On Sun, Oct 21, 2012 at 08:23:35AM +0000, Paul Walmsley wrote:
> > On Sun, 21 Oct 2012, Richard Cochran wrote:
> >
> > > When I read your report, it gave me a much rosier picture than is
> > > actually the case WRT the beaglebone.
> >
> > Really? What section of the message provided that to you?
>
> It was the part that said,
>
> Passing tests
> -------------
>
> Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm,
> 4430es2panda, 5912osk, am335xbone
>
> It sounded to me like you were saying that the current kernel release
> boots just fine on the beaglebone, with no issues.
Which it does here, on the configuration described earlier:
http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/boot/am335xbone/am335xbone_log.txt
- Paul
^ permalink raw reply
* [PATCH] ARM: dts: exynos4: Enable serial controllers on Origen and SMDKV310
From: Tomasz Figa @ 2012-10-21 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10e401cdaae0$a17d44b0$e477ce10$%kim@samsung.com>
Hi Kgene,
On Monday 15 of October 2012 23:23:22 Kukjin Kim wrote:
> Tomasz Figa wrote:
> > Hi Kgene,
> >
> > On Monday 08 of October 2012 15:12:48 Tomasz Figa wrote:
> > > This patch adds status override of serial nodes to enable used
> > > serial
> > > ports on Origen and SMDKV310 board.
> > >
> > > Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> > > ---
> > >
> > > arch/arm/boot/dts/exynos4210-origen.dts | 16 ++++++++++++++++
> > > arch/arm/boot/dts/exynos4210-smdkv310.dts | 16 ++++++++++++++++
> > > 2 files changed, 32 insertions(+)
> >
> > I think you missed this patch when applying Exynos dts reorganization
> > patches. It is needed to enable serial ports on Origen and SMDKV310
>
> boards.
>
> > Could you apply it as well?
>
> Oops, yeah. I will apply.
I saw that you applied this patch to your next/dt-samsung branch, thanks.
However I think this should be considered a fix, because without it serial
console on Origen and SMDKV310 will be broken.
Best regards,
Tomasz Figa
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Paul Walmsley @ 2012-10-21 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121021135143.GA1855@beef>
On Sun, 21 Oct 2012, Matt Porter wrote:
> On Sat, Oct 20, 2012 at 06:58:10PM +0000, Paul Walmsley wrote:
>
> > TI also has a u-boot tree for the AM33xx; might be worth trying:
> >
> > git://arago-project.org/git/projects/u-boot-am33x.git
>
> Use of the vendor tree should be discouraged.
That's good. Maybe someone can drop a comment to that effect into the top
of the arago u-boot README?
- Paul
^ permalink raw reply
* OMAP baseline test results for v3.7-rc2
From: Paul Walmsley @ 2012-10-21 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210202125300.774@utopia.booyaka.com>
On Sat, 20 Oct 2012, Paul Walmsley wrote:
> Here are some basic OMAP test results for Linux v3.7-rc2.
> Logs and other details at:
>
> http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
...
> Failing tests: needing investigation
> ------------------------------------
>
> PM tests:
>
> * 37xx EVM: CORE not entering dynamic off-idle
> - Cause unknown; dynamic retention-idle seems to work; system suspend to
> off works
Just confirmed that this longstanding bug affects both MMC root and NFS
root.
- Paul
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Florian Fainelli @ 2012-10-21 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350771032-11527-3-git-send-email-linux@prisktech.co.nz>
Le dimanche 21 octobre 2012 00:10:32, Tony Prisk a ?crit :
> Add a binding document for ehci-platform driver.
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> ---
> .../devicetree/bindings/usb/ehci-platform.txt | 27
> ++++++++++++++++++++ 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/ehci-platform.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/ehci-platform.txt
> b/Documentation/devicetree/bindings/usb/ehci-platform.txt new file mode
> 100644
> index 0000000..930b19e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/ehci-platform.txt
> @@ -0,0 +1,27 @@
> +Generic Platform EHCI Controller
> +-----------------------------------------------------
> +
> +Required properties:
> +- compatible : "linux,ehci-platform"
Here you changed to linux,ehci-platform, which is good, but in the example you
forgot to update it.
Otherwise, this is ok with me.
> +- reg : Should contain 1 register ranges(address and length)
> +- interrupts : EHCI controller interrupt
> +
> +Optional properties:
> +- caps-offset : offset to the capabilities register (default = 0)
> +- has-tt : controller has transaction translator(s).
> +- has-synopsys-hc-bug : controller has the synopsys hc bug
> +- no-io-watchdog : controller does not need io watchdog
> +
> +- big-endian : descriptors and registers are both big endian. This
> + is the equivalent of specifying big-endian-desc and big-endian-regs.
> +OR
> +- big-endian-desc : descriptors are in big-endian format
> +- big-endian-regs : mmio is in big-endian format
> +
> +Example:
> + ehci at d8007c00 {
> + compatible = "ehci-platform";
> + reg = <0xd8007c00 0x200>;
> + interrupts = <43>;
> + has-tt;
> + };
--
Florian
^ permalink raw reply
* [RFC 00/11] Convert Kirkwood to pinctrl
From: Andrew Lunn @ 2012-10-21 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121021115716.GA22437@schnuecks.de>
On Sun, Oct 21, 2012 at 01:57:16PM +0200, Simon Baatz wrote:
> Hi Andrew,
>
> On Sat, Oct 20, 2012 at 05:07:32PM +0200, Andrew Lunn wrote:
> > This patchset converts all kirkwood DT boards to pinctrl.
> > It is an RFC for a number of reasons:
> >
>
>
> It seems that the mails with the actual patches somehow got lost. If
> it is not too much work, could you provide these patches also via
> your git repository on github?
Hi Simon
Yes, the list server did not like them for some reason. Seams to work
sometimes, not others.
Anyway:
git://github.com/lunn/linux.git v3.7-rc1-pinctrl
Once i have all the CPU variants, i will repost the patchset.
Andrew
^ permalink raw reply
* [PATCH 2/2] ARM: kirkwood: use gpio-fan DT binding on lsxl
From: Andrew Lunn @ 2012-10-21 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210211559.38628.michael@walle.cc>
> > Hi Michael
> >
> > You might also be able to remove platform_device.h.
>
> Mh, pm_power_off, although defined in linux/pm.h, is somehow pulled with this
> include. So either we leave it that way (looking at other boards only a few
> has included pm.h) or i'll post a third patch which replaces that include.
O.K, leave it as it is.
I hope to look at a DT solution for pm_power_off sometime soon.
Andrew
^ permalink raw reply
* [PATCH 3/9] uprobes: allow ignoring of probe hits
From: Rabin Vincent @ 2012-10-21 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017173510.GA11019@redhat.com>
On Wed, Oct 17, 2012 at 07:35:10PM +0200, Oleg Nesterov wrote:
> On 10/16, Rabin Vincent wrote:
> > 2012/10/15 Oleg Nesterov <oleg@redhat.com>:
> > > Not sure I understand why we shouldn't call handlers in this case,
> > > but OK, I know nothing about arm.
> >
> > This old discussion about kprobes should be useful:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/045755.html
>
> Thanks... Not sure I understand this discussion...
>
> And, to clarify, I am not arguing. Just curious.
>
> So, is this like cmov on x86? And this patch allows to not report if
> the condition is not true? Or there are other issues on arm?
Yes, I guess this is like CMOV on x86. In the ARM instruction set most
instructions can be conditionally executed.
In order to set the probe on a conditional instruction, we use an
undefined instruction with the same condition as the instruction we
replace. However, it is implementation defined whether an undefined
instruction with a failing condition code will trigger an undefined
instruction exception or just be executed as a NOP. So for those
processor implementations where we do get the undefined instruction
exception even for a failing condition code, we have to ignore it in
order to provide consistent behaviour.
^ permalink raw reply
* [PATCH 3/5] net/at91_ether: move eth addr quirk into csb337 board setup
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-21 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350829392-3812-4-git-send-email-manabian@gmail.com>
On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
> Move Ethernet address byte order fix for csb337 into it's board
> setup.
>
> This will allow us to remove the last mach include from at91_ether
> and also to share the address setup with the macb driver.
no the at91rm9200 move to DT this is not compatible with it
you need to pass ths in info via platform_data
and do not touch driver code related stuff in boards
Best Regards,
J.
>
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
> ---
> arch/arm/mach-at91/board-csb337.c | 35 +++++++++++++++++++++++++++++++
> drivers/net/ethernet/cadence/Kconfig | 1 -
> drivers/net/ethernet/cadence/at91_ether.c | 26 ++++++-----------------
> 3 files changed, 41 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-at91/board-csb337.c b/arch/arm/mach-at91/board-csb337.c
> index 3e37437..5522132 100644
> --- a/arch/arm/mach-at91/board-csb337.c
> +++ b/arch/arm/mach-at91/board-csb337.c
> @@ -217,6 +217,40 @@ static struct gpio_led csb_leds[] = {
> }
> };
>
> +/*
> + * MicroMonitor (uMon) on the CSB337 store the ethernet address in the
> + * wrong byte order (and continues to do so, for bug-compatibility).
> + */
> +#define MACB_SA1B 0x0098
> +#define MACB_SA1T 0x009c
> +static void __init csb337_fix_eth_addr(void)
> +{
> + void __iomem *emac;
> + u32 lo, hi, tmp;
> + int i;
> +
> + emac = ioremap(AT91RM9200_BASE_EMAC, SZ_16K);
> + if (!emac) {
> + printk(KERN_ERR "csb337: unable to fixup Ethernet address\n");
> + return;
> + }
> +
> + /* Fix byte order on all 4 address registers */
> + for (i = 0; i < 4; i++) {
> + lo = readl(emac + MACB_SA1B + i * 8);
> + hi = readl(emac + MACB_SA1T + i * 8);
> +
> + tmp = (lo & 0xff) << 8 | (lo & 0xff00) >> 8;
> + writel(tmp, emac + MACB_SA1T + i * 8);
> +
> + tmp = (hi & 0xff) << 8 | (hi & 0xff00) >> 8
> + | (lo & 0xff0000) << 8
> + | (lo & 0xff000000) >> 8;
> + writel(tmp, emac + MACB_SA1B + i * 8);
> + }
> +
> + iounmap(emac);
> +}
>
> static void __init csb337_board_init(void)
> {
> @@ -225,6 +259,7 @@ static void __init csb337_board_init(void)
> at91_register_uart(0, 0, 0);
> at91_add_device_serial();
> /* Ethernet */
> + csb337_fix_eth_addr();
> at91_add_device_eth(&csb337_eth_data);
> /* USB Host */
> at91_add_device_usbh(&csb337_usbh_data);
> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
> index f6d0956..40172d1 100644
> --- a/drivers/net/ethernet/cadence/Kconfig
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -21,7 +21,6 @@ if NET_CADENCE
>
> config ARM_AT91_ETHER
> tristate "AT91RM9200 Ethernet support"
> - depends on ARM && ARCH_AT91RM9200
> select NET_CORE
> select MACB
> ---help---
> diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
> index 375d272..5ed1a63 100644
> --- a/drivers/net/ethernet/cadence/at91_ether.c
> +++ b/drivers/net/ethernet/cadence/at91_ether.c
> @@ -32,8 +32,6 @@
> #include <linux/phy.h>
> #include <linux/io.h>
>
> -#include <asm/mach-types.h>
> -
> #include "macb.h"
>
> #define DRV_NAME "at91_ether"
> @@ -55,30 +53,18 @@
> * U-Boot on the AT91RM9200-DK do not do this.
> *
> * - Likewise it must store the addresses in the correct byte order.
> - * MicroMonitor (uMon) on the CSB337 does this incorrectly (and
> - * continues to do so, for bug-compatibility).
> */
>
> static short __init unpack_mac_address(struct net_device *dev, unsigned int hi, unsigned int lo)
> {
> char addr[6];
>
> - if (machine_is_csb337()) {
> - addr[5] = (lo & 0xff); /* The CSB337 bootloader stores the MAC the wrong-way around */
> - addr[4] = (lo & 0xff00) >> 8;
> - addr[3] = (lo & 0xff0000) >> 16;
> - addr[2] = (lo & 0xff000000) >> 24;
> - addr[1] = (hi & 0xff);
> - addr[0] = (hi & 0xff00) >> 8;
> - }
> - else {
> - addr[0] = (lo & 0xff);
> - addr[1] = (lo & 0xff00) >> 8;
> - addr[2] = (lo & 0xff0000) >> 16;
> - addr[3] = (lo & 0xff000000) >> 24;
> - addr[4] = (hi & 0xff);
> - addr[5] = (hi & 0xff00) >> 8;
> - }
> + addr[0] = (lo & 0xff);
> + addr[1] = (lo & 0xff00) >> 8;
> + addr[2] = (lo & 0xff0000) >> 16;
> + addr[3] = (lo & 0xff000000) >> 24;
> + addr[4] = (hi & 0xff);
> + addr[5] = (hi & 0xff00) >> 8;
>
> if (is_valid_ether_addr(addr)) {
> memcpy(dev->dev_addr, &addr, 6);
> --
> 1.7.12.4
>
^ permalink raw reply
* [PATCH 9/9] ARM: add uprobes support
From: Rabin Vincent @ 2012-10-21 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015173147.GA18614@linaro.org>
On Mon, Oct 15, 2012 at 06:31:47PM +0100, Dave Martin wrote:
> On Sun, Oct 14, 2012 at 09:23:13PM +0200, Rabin Vincent wrote:
> > +static int uprobe_trap_handler(struct pt_regs *regs, unsigned int instr)
> > +{
> > + unsigned long flags;
> > +
> > + local_irq_save(flags);
> > + if ((instr & 0x0fffffff) == UPROBE_SWBP_INSN)
>
> Is the check unnecessary here? I think the same comparison will
> happen as a result of evaluating the associated undef_hook.
The check is there because this uprobe_trap_handler() is registered for
two different undefined instructions: UPROBE_SWBP_INSN (the one which is
used to insert the probe) and UPROBE_SS_INSN (the one placed in the XOL
area for simulating single-stepping).
^ permalink raw reply
* [PATCH 1/5] net/cadence: get rid of HAVE_NET_MACB
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-21 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350829392-3812-2-git-send-email-manabian@gmail.com>
On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
> macb is a platform driver and there is nothing that prevents
> this driver from being built on non-ARM/AVR32 platforms.
if you want to drop the HAVE_NET_MACB you need to drop it everywher in one
patch
Best Regards,
J.
>
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
> ---
> drivers/net/ethernet/cadence/Kconfig | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
> index 57f78abe..5d1ea30 100644
> --- a/drivers/net/ethernet/cadence/Kconfig
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -2,13 +2,9 @@
> # Atmel device configuration
> #
>
> -config HAVE_NET_MACB
> - bool
> -
> config NET_CADENCE
> bool "Cadence devices"
> default y
> - depends on HAVE_NET_MACB || (ARM && ARCH_AT91RM9200)
> ---help---
> If you have a network (Ethernet) card belonging to this class, say Y.
> Make sure you know the name of your card. Read the Ethernet-HOWTO,
> @@ -34,7 +30,6 @@ config ARM_AT91_ETHER
>
> config MACB
> tristate "Cadence MACB/GEM support"
> - depends on HAVE_NET_MACB
> select PHYLIB
> ---help---
> The Cadence MACB ethernet interface is found on many Atmel AT32 and
> --
> 1.7.12.4
>
^ permalink raw reply
* [PATCH 2/5] net/at91_ether: select MACB in Kconfig
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-21 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350829392-3812-3-git-send-email-manabian@gmail.com>
On 16:23 Sun 21 Oct , Joachim Eastwood wrote:
> Now that HAVE_NET_MACB is gone let's just select MACB to
> satisfy the dependecies in at91_ether.
>
> PHYLIB will then by selected by MACB.
>
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
> ---
> drivers/net/ethernet/cadence/Kconfig | 2 +-
> drivers/net/ethernet/cadence/Makefile | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
> index 5d1ea30..f6d0956 100644
> --- a/drivers/net/ethernet/cadence/Kconfig
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -23,7 +23,7 @@ config ARM_AT91_ETHER
> tristate "AT91RM9200 Ethernet support"
> depends on ARM && ARCH_AT91RM9200
> select NET_CORE
> - select PHYLIB
> + select MACB
no the ether and macb are two diferrent drivers for 2 IPs from cadence
the ehter does not need the macb
Best Regards,
J.
> ---help---
> If you wish to compile a kernel for the AT91RM9200 and enable
> ethernet support, then you should always answer Y to this.
> diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
> index 798b1e0..9068b83 100644
> --- a/drivers/net/ethernet/cadence/Makefile
> +++ b/drivers/net/ethernet/cadence/Makefile
> @@ -2,5 +2,5 @@
> # Makefile for the Atmel network device drivers.
> #
>
> -obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o macb.o
> +obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
> obj-$(CONFIG_MACB) += macb.o
> --
> 1.7.12.4
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox