Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Tue, May 08, 2007 at 10:29:03AM +0200, Tomasz Chmielewski wrote: Michael Jones wrote: +#ifndef __ARMEB__ +#warning Little endian mode not supported +#endif Personally I'm less fussed about WAN / LE support. Anyone with any sense will run ixp4xx boards doing such a specialised network operation as BE. Also, NSLU2-Linux can't test this functionality with our LE setup as we don't have this hardware on-board. You may just want to declare a depends on ARMEB in Kconfig (with or without OR (ARM || BROKEN) ) and have done with it - it's up to you. Christian Hohnstaedt's work did support LE though. Not all ixp4xx boards are by definition doing such a specialised network operation. Krzysztof, why is LE not supported? Do you need access to ixp4xx that starts in LE mode? Not even trying to support LE is a clear merge blocker. Maybe Krzysztof can't actually test it himself, which is fine - but not even pretending to be endian clean is not what proper Linux drivers do. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Wed, May 16, 2007 at 08:13:01AM +0100, Christoph Hellwig wrote: +#ifndef __ARMEB__ +#warning Little endian mode not supported +#endif Personally I'm less fussed about WAN / LE support. Anyone with any sense will run ixp4xx boards doing such a specialised network operation as BE. Also, NSLU2-Linux can't test this functionality with our LE setup as we don't have this hardware on-board. You may just want to declare a depends on ARMEB in Kconfig (with or without OR (ARM || BROKEN) ) and have done with it - it's up to you. Christian Hohnstaedt's work did support LE though. Not all ixp4xx boards are by definition doing such a specialised network operation. Krzysztof, why is LE not supported? Do you need access to ixp4xx that starts in LE mode? Not even trying to support LE is a clear merge blocker. Maybe Krzysztof can't actually test it himself, which is fine - but not even pretending to be endian clean is not what proper Linux drivers do. The issue is not that the driver is not 'endian clean'. This is a driver for an on-chip ethernet MAC on an ARM CPU. I.e. the ethernet MAC is on the CPU itself, it's not some kind of PCI device or something like that. The ARM CPU in question can be run in either little endian or big endian mode. Making a driver work in both modes of operation is generally not just an issue of adding a couple of be32_to_cpu()s in the right places. For example, intel IXP2000 and IXP23xx CPU support in arch/arm only supports big-endian mode of operation, and none of the associated drivers support little-endian mode. Most of the other CPU support in arch/arm only supports little-endian mode, and none of the associated drivers support big-endian mode. According to your criterion, that would mean that most of the ARM drivers (alsa, usb, framebuffer, networking, etc.) should never have been accepted in the kernel tree in the first place. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On 16 May 2007, at 10:41, Lennert Buytenhek wrote: Making a driver work in both modes of operation is generally not just an issue of adding a couple of be32_to_cpu()s in the right places. While this comment is technically correct, Christian's driver achieves endian agnostic operation with only 10 additional lines of code [1]. Thus, there is no reason to assume that gaining LE support will be a major issue. Michael-Luke [1] http://www.hohnstaedt.de/ixp_npe/0.3.1/ixp4xx_npe_driver-0.3.1.diff Search in this file for swap the payload of the SKB (it's in mac_driver.c) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Lots of people wrote: Lots of huffing and puffing about endian support by this driver ... For what it's worth, the NSLU2-Linux project (which has over 10,000 known users of our custom ixp4xx firmware, most of which will eventually be users of this new driver) is *endian-neutral*. We support both big-endian and little-endian usage of the ixp4xx in a number of consumer devices like the NSLU2, NAS100d, DSMG600, and FSG3. We are very interested in getting this driver into mainline in the most expedient and correct fashion acceptable to the relevant mainline maintainers. We have also discussed this situation with the author of the previous set of ixp4xx open-source ethernet driver patches, and he also recommends that we put our support behind this new set of patches. So, if the author of these patches wishes to concentrate on big-endian support first, then we will not say (and have not said) anything which will block inclusion of a big-endian only version of this driver. In parallel to this initial upstream push, we will be working with the author to make sure that this driver supports little-endian devices as well (as we are endian-neutral in our project's support of consumer devices based on the ixp4xx). If we get this done before upstream acceptance of the big-endian version, that will be great. If we don't, then we'll work to hit the next merge window. We will create a functionally correct little-endian version first (the simple byte-swapping implementation) and will work on a performance-enhanced version later (if that is even possible without prohibitive massive upstream changes). There simply is no reason for everyone to be arguing about this. Remember that what we are seeing here is an open-source replacement for a long-time proprietary driver. We should all rejoice in that, support the author of these patches, and not fight amongst ourselves. -- Rod Whitby -- NSLU2-Linux Project Lead - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Wed, May 16, 2007 at 08:16:38PM +0930, Rod Whitby wrote: So, if the author of these patches wishes to concentrate on big-endian support first, then we will not say (and have not said) anything which will block inclusion of a big-endian only version of this driver. The NSLU2 people are the ones here that are saying that the driver should really support LE (because that is what they happen to be using, the rest of the world runs the ixp4xx in BE), and they keep saying that it would be so easy to make a patch to add LE support, but so far they haven't produced such a patch. Please just write the patch and let's get this over with. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Lennert Buytenhek wrote: On Wed, May 16, 2007 at 08:16:38PM +0930, Rod Whitby wrote: So, if the author of these patches wishes to concentrate on big-endian support first, then we will not say (and have not said) anything which will block inclusion of a big-endian only version of this driver. The NSLU2 people are the ones here that are saying that the driver should really support LE (because that is what they happen to be using, the rest of the world runs the ixp4xx in BE) I'll repeat again. NSLU2-Linux supports both BE and LE. We have about 5,000 users running BE and about 5,000 users running LE. Perhaps you're confusing the NSLU2-Linux project (which official supports both endians equally) with the Debian project (which official supports only LE, and has an unofficial BE port). One NSLU2-Linux person said they would prefer the driver to support LE, but would be happy for it to be marked BE only in the Kconfig as an alternative. That is consistent with what I wrote in my message. Please just write the patch and let's get this over with. Please let's just stop arguing about it. If a patch appears before it gets merged, then great. If it doesn't then it will appear at a later date. -- Rod - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Wed, May 16, 2007 at 09:05:18PM +0930, Rod Whitby wrote: So, if the author of these patches wishes to concentrate on big-endian support first, then we will not say (and have not said) anything which will block inclusion of a big-endian only version of this driver. The NSLU2 people are the ones here that are saying that the driver should really support LE (because that is what they happen to be using, the rest of the world runs the ixp4xx in BE) I'll repeat again. NSLU2-Linux supports both BE and LE. We have about 5,000 users running BE and about 5,000 users running LE. Perhaps, but somehow I don't think that we'd have seen any reaction if the submitted driver had only supported LE and not BE. Please just write the patch and let's get this over with. Please let's just stop arguing about it. If a patch appears before it gets merged, then great. If it doesn't then it will appear at a later date. Great. I agree. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Christoph Hellwig [EMAIL PROTECTED] writes: Not even trying to support LE is a clear merge blocker. Maybe Krzysztof can't actually test it himself, which is fine - but not even pretending to be endian clean is not what proper Linux drivers do. The drivers can only work with IXP4xx CPU and that's not the typical endianess problem cross-platform drivers sometimes have. There is different functionality required with LE mode, unless some other arch changes are implemented (which I'm now researching, if I have some time of course). -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Rod Whitby [EMAIL PROTECTED] writes: Please let's just stop arguing about it. If a patch appears before it gets merged, then great. If it doesn't then it will appear at a later date. Sure. The swapping patch is trivial and I can add it if needed at some point but I hope we can do that data coherency mode right. Personally I'd be pleased if I could run the board LE instead of BE, with no performance penalty. -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Wed, May 09, 2007 at 03:45:53PM +0100, Michael-Luke Jones wrote: No-one is saying that this driver should not be mainlined before it has LE support. All that I said was: Personally I'd like LE ethernet tested and working before we push. The alternative would be to explicitly state in Kconfig that LE arm is broken with this driver, so that this could be fixed later. The driver does bomb out during compile if __ARMEB__ isn't defined, but that apparently wasn't good enough. Please can we not blow this out of proportion, it really isn't that big a deal. The irony is that fixing Krzysztof's driver to work on LE will probably be quite easy, given that we already have a working LE driver from Christian. I'm looking forward to your patch. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Krzysztof Halasa wrote: Lennert Buytenhek [EMAIL PROTECTED] writes: There _is_ an ARM BE version of Debian. It's not an official port, but it's not maintained any worse than the 'official' LE ARM Debian port is. Hmm... That changes a bit. Perhaps we should forget about that LE thing then, and (at best) put that trivial workaround? Please keep in mind that users are unlikely to install an unofficial port which lacks integration with the Debian infrastructure, security support and other services. The arm architecture (LE) is currently the third most popular in Debian, whereas I suspect (?) there are very few BE Debian systems out there. Marcus - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Wed, May 09, 2007 at 10:58:06AM +0200, Marcus Better wrote: There _is_ an ARM BE version of Debian. It's not an official port, but it's not maintained any worse than the 'official' LE ARM Debian port is. Hmm... That changes a bit. Perhaps we should forget about that LE thing then, and (at best) put that trivial workaround? Please keep in mind that users are unlikely to install an unofficial port which lacks integration with the Debian infrastructure, security support and other services. The arm architecture (LE) is currently the third most popular in Debian, whereas I suspect (?) there are very few BE Debian systems out there. Note that all of your arguments also apply to the experimental EABI little-endian ARM port. I.e.: 1. The EABI port is an unofficial port. 2. The EABI port is not integrated with the Debian infrastructure. 3. The EABI port lacks security support. You could also argue that: 4. There is no reason to use EABI -- old-ABI works just as well. 5. The perceived floating point speedups that EABI gives are completely drowned out by the slowness of the rest of the system. 6. A lot of programs assume old-ABI behavior, it is too much work to patch them all. Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better? I think you've just summarised why I don't like working on Debian. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Lennert Buytenhek wrote: Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better? Well, I am not one of the Debian ARM people, just a user... and I do hope the EABI port becomes supported in the future! But in the meatime there is a crowd of users running Debian on consumer devices like the NSLU2, and they need a LE network driver. Marcus pgpXZAXckxl8V.pgp Description: PGP signature
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Wed, 9 May 2007 11:35:03 +0200, Marcus Better wrote: Lennert Buytenhek wrote: Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better? Well, I am not one of the Debian ARM people, just a user... and I do hope the EABI port becomes supported in the future! But in the meatime there is a crowd of users running Debian on consumer devices like the NSLU2, and they need a LE network driver. 1) Development _should_ happen in small individually-manageable steps. It's wrong to delay integration of the new IXP4xx eth driver just because it's not yet LE-compatible. 2) LE Debian/ARM users do have alternatives: they can use USB-Ethernet adapters, for instance. /Mikael - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Wed, 9 May 2007 11:35:03 +0200, Marcus Better wrote: Lennert Buytenhek wrote: Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better? Well, I am not one of the Debian ARM people, just a user... and I do hope the EABI port becomes supported in the future! But in the meatime there is a crowd of users running Debian on consumer devices like the NSLU2, and they need a LE network driver. 1) Development _should_ happen in small individually-manageable steps. It's wrong to delay integration of the new IXP4xx eth driver just because it's not yet LE-compatible. True. 2) LE Debian/ARM users do have alternatives: they can use USB-Ethernet adapters, for instance. In case of Freecom FSG-3, that would be four USB-ethernet adapters. With the cost roughly half of the cost of the whole device. And all USB-ports occupied. Provided you don't use them for something else. Someone could ask why has this device four mice connected? :) (for someone who doesn't work much with computers, a USB-ISDN or USB-ethernet adapter looks just like a mouse). And yet another viable alternative is to use a totally different device which is fully supported under Linux or another system, right? :) -- Tomasz Chmielewski http://wpkg.org - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Wed, May 09, 2007 at 11:35:03AM +0200, Marcus Better wrote: Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better? Well, I am not one of the Debian ARM people, just a user... and I do hope the EABI port becomes supported in the future! But in the meatime there is a crowd of users running Debian on consumer devices like the NSLU2, and they need a LE network driver. There's a crowd of users running Linux on TCP offload capable cards, and they need TCP offload support in Linux. The people who need a LE network driver can use Christian's driver, as Christian's driver works in LE just fine. The people who care about LE support can add LE support to the driver that Krzysztof wrote. I don't think that not supporting LE is a reason not to merge Krzysztof's driver. Don't make supporting LE systems Krzysztof's problem. Krzysztof has written an excellent driver, and while it would be 100% Debian style to reject his driver just because it doesn't support LE[*], thankfully, Linux is not Debian. Please don't turn Linux into Debian. [*] And if he were to complain about this, he would get slapped with the standard Our priorities are our users and free software Debian Social Contract rhetoric -- thank $DEITY we don't have a Linux Kernel Social Contract with the same bullshit in it. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Wed, May 09, 2007 at 12:35:40PM +0200, Mikael Pettersson wrote: Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better? Well, I am not one of the Debian ARM people, just a user... and I do hope the EABI port becomes supported in the future! But in the meatime there is a crowd of users running Debian on consumer devices like the NSLU2, and they need a LE network driver. 1) Development _should_ happen in small individually-manageable steps. It's wrong to delay integration of the new IXP4xx eth driver just because it's not yet LE-compatible. Exactly. 2) LE Debian/ARM users do have alternatives: they can use USB-Ethernet adapters, for instance. Or just use Christian's driver. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Lennert Buytenhek wrote: The people who need a LE network driver can use Christian's driver, as Christian's driver works in LE just fine. The people who care about LE support can add LE support to the driver that Krzysztof wrote. I don't think that not supporting LE is a reason not to merge Krzysztof's driver. Don't make supporting LE systems Krzysztof's problem. Krzysztof has written an excellent driver, and while it would be 100% Debian style to reject his driver just because it doesn't support LE[*], thankfully, Linux is not Debian. Please don't turn Linux into Debian. I am using the ixp425 on the avila from gateworks. It only has 16 MB of flash built in. We needed to squeeze a production and a failsafe linux inside that so debian was not an option. I found intel's original drivers horrible to read, maintain, and use. We are using Cristian's driver (rev 0.2.1) and are preparing to go to his latest for the crypto support. I only had one bug in 0.2.1, which is fixed in later versions. I would love to see mail line support for this device, including the ethernet ports and the crypto capabilities. We run in big endian despite the extra difficulty in toolset setup and finding lots of brain0-damaged-designed-for-x86 code. We already can use up the CPU when we have the mini-pci slots populated with 802.11g radios and the ethernet port in use. Swapping packets would kill us. Never mind if we do any kind of software based crypto! For those of us in the embedded space, performance matters. Big endian is the natural setup for the NPEs on this hardware according to the intel documentation. Please don't stop this driver from moving forward so that a few folks can run their hardware in slow mode. -Ack - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On 9 May 2007, at 15:22, David Acker wrote: Big endian is the natural setup for the NPEs on this hardware according to the intel documentation. Please don't stop this driver from moving forward so that a few folks can run their hardware in slow mode. No-one is saying that this driver should not be mainlined before it has LE support. All that I said was: Personally I'd like LE ethernet tested and working before we push. The alternative would be to explicitly state in Kconfig that LE arm is broken with this driver, so that this could be fixed later. Please can we not blow this out of proportion, it really isn't that big a deal. The irony is that fixing Krzysztof's driver to work on LE will probably be quite easy, given that we already have a working LE driver from Christian. Michael-Luke PS: It really isn't just 'a few folks' - at NSLU2-Linux we have 5000 people who have downloaded Debian/LE for NSLU2 and are currently using Christian's driver with great success. We would just like to replicate that support with this new driver. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On 8 May 2007, at 02:19, Krzysztof Halasa wrote:
Adds a driver for built-in IXP4xx Ethernet MAC and HSS ports
Signed-off-by: Krzysztof Halasa [EMAIL PROTECTED]
diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c b/arch/arm/mach-
ixp4xx/ixdp425-setup.c
index ec4f079..f20d39d 100644
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -101,10 +101,35 @@ static struct platform_device ixdp425_uart = {
.resource = ixdp425_uart_resources
};
+/* Built-in 10/100 Ethernet MAC interfaces */
+static struct mac_plat_info ixdp425_plat_mac[] = {
+ {
+ .phy= 0,
+ .rxq= 3,
+ }, {
+ .phy= 1,
+ .rxq= 4,
+ }
+};
+
+static struct platform_device ixdp425_mac[] = {
+ {
+ .name = ixp4xx_eth,
+ .id = IXP4XX_ETH_NPEB,
+ .dev.platform_data = ixdp425_plat_mac,
+ }, {
+ .name = ixp4xx_eth,
+ .id = IXP4XX_ETH_NPEC,
+ .dev.platform_data = ixdp425_plat_mac + 1,
+ }
+};
+
static struct platform_device *ixdp425_devices[] __initdata = {
ixdp425_i2c_controller,
ixdp425_flash,
- ixdp425_uart
+ ixdp425_uart,
+ ixdp425_mac[0],
+ ixdp425_mac[1],
};
static void __init ixdp425_init(void)
A final submission should probably have this platform data separated
from the net driver and sent upstream via Russell's patch tracking
system rather than netdev.
diff --git a/drivers/net/arm/Kconfig b/drivers/net/arm/Kconfig
index 678e4f4..5e2acb6 100644
--- a/drivers/net/arm/Kconfig
+++ b/drivers/net/arm/Kconfig
@@ -46,3 +46,13 @@ config EP93XX_ETH
help
This is a driver for the ethernet hardware included in EP93xx
CPUs.
Say Y if you are building a kernel for EP93xx based devices.
+
+config IXP4XX_ETH
+ tristate IXP4xx Ethernet support
+ depends on NET_ETHERNET ARM ARCH_IXP4XX
+ select IXP4XX_NPE
+ select IXP4XX_QMGR
+ select MII
+ help
+ Say Y here if you want to use built-in Ethernet ports
+ on IXP4xx processor.
diff --git a/drivers/net/arm/Makefile b/drivers/net/arm/Makefile
index a4c8682..7c812ac 100644
--- a/drivers/net/arm/Makefile
+++ b/drivers/net/arm/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_ARM_ETHER3)+= ether3.o
obj-$(CONFIG_ARM_ETHER1) += ether1.o
obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
obj-$(CONFIG_EP93XX_ETH) += ep93xx_eth.o
+obj-$(CONFIG_IXP4XX_ETH) += ixp4xx_eth.o
diff --git a/drivers/net/arm/ixp4xx_eth.c b/drivers/net/arm/
ixp4xx_eth.c
new file mode 100644
index 000..dcea6e5
--- /dev/null
+++ b/drivers/net/arm/ixp4xx_eth.c
@@ -0,0 +1,1002 @@
+/*
+ * Intel IXP4xx Ethernet driver for Linux
+ *
+ * Copyright (C) 2007 Krzysztof Halasa [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of version 2 of the GNU General Public License
+ * as published by the Free Software Foundation.
+ *
+ * Ethernet port config (0x00 is not present on IXP42X):
+ *
+ * logical port0x000x100x20
+ * NPE 0 (NPE-A) 1 (NPE-B) 2 (NPE-C)
+ * physical PortId 2 0 1
+ * TX queue23 24 25
+ * RX-free queue 26 27 28
+ * TX-done queue is always 31, RX queue is configurable
+ */
+
+#include linux/delay.h
+#include linux/dma-mapping.h
+#include linux/dmapool.h
+#include linux/kernel.h
+#include linux/mii.h
+#include linux/platform_device.h
+#include asm/io.h
+#include asm/arch/npe.h
+#include asm/arch/qmgr.h
+
+#ifndef __ARMEB__
+#warning Little endian mode not supported
+#endif
This has gone from error to warning - fair play but if are planning
to put this upstream this cycle (anything's possible :) ) you'll want
to declare this driver broken on ARMEB in Kconfig please.
Personally I'd like LE ethernet tested and working before we push.
+
+#define DEBUG_QUEUES 0
+#define DEBUG_RX 0
+#define DEBUG_TX 0
+#define DEBUG_PKT_BYTES0
+#define DEBUG_MDIO 0
+
+#define DRV_NAME ixp4xx_eth
+#define DRV_VERSION0.04
+
+#define TX_QUEUE_LEN 16 /* dwords */
+#define PKT_DESCS 64 /* also length of queues: TX-done, RX-ready,
RX */
+
+#define POOL_ALLOC_SIZE(sizeof(struct desc) * (PKT_DESCS))
+#define REGS_SIZE 0x1000
+#define MAX_MRU1536
+
+#define MDIO_INTERVAL (3 * HZ)
+#define MAX_MDIO_RETRIES 100 /* microseconds, typically 30 cycles */
+
+#define NPE_ID(port) ((port)-id 4)
+#define PHYSICAL_ID(port) ((NPE_ID(port) + 2) % 3)
+#define TX_QUEUE(plat) (NPE_ID(port) + 23)
+#define
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On 8 May 2007, at 09:26, Mikael Pettersson wrote: On Tue, 8 May 2007 08:22:17 +0100, Michael-Luke Jones wrote: AFAIK, it's a HW limitation of the IXP4xx NPEs, or possibly Intel's microcode for them. I run my IXP42x boxes big-endian and don't mind doing so. /Mikael *cough* http://www.hohnstaedt.de/ixp_npe/0.2.0/0001-IXP4XX-Driver-for-NPE- QMGR-MAC-0.2.0.txt :p --- On 8 May 2007, at 09:29, Tomasz Chmielewski wrote: Christian Hohnstaedt's work did support LE though. Indeed. Krzysztof, why is LE not supported? Butting in here. It's not supported because LE mode has to work in a brain-damaged way. NPE DMAs the complete skb straight out of RAM. Unfortunately it expects the skb to already be written out in ram BE. Thus, in LE mode we have to byteswap the skb with CPU before the NPE can DMA it. This hasn't been implemented yet. Michael-Luke Jones - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Tue, 8 May 2007 08:22:17 +0100, Michael-Luke Jones wrote: On 8 May 2007, at 02:19, Krzysztof Halasa wrote: Adds a driver for built-in IXP4xx Ethernet MAC and HSS ports ... +#ifndef __ARMEB__ +#warning Little endian mode not supported +#endif This has gone from error to warning - fair play but if are planning to put this upstream this cycle (anything's possible :) ) you'll want to declare this driver broken on ARMEB in Kconfig please. Personally I'd like LE ethernet tested and working before we push. AFAIK, it's a HW limitation of the IXP4xx NPEs, or possibly Intel's microcode for them. I run my IXP42x boxes big-endian and don't mind doing so. /Mikael - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Michael Jones wrote: +#ifndef __ARMEB__ +#warning Little endian mode not supported +#endif Personally I'm less fussed about WAN / LE support. Anyone with any sense will run ixp4xx boards doing such a specialised network operation as BE. Also, NSLU2-Linux can't test this functionality with our LE setup as we don't have this hardware on-board. You may just want to declare a depends on ARMEB in Kconfig (with or without OR (ARM || BROKEN) ) and have done with it - it's up to you. Christian Hohnstaedt's work did support LE though. Not all ixp4xx boards are by definition doing such a specialised network operation. Krzysztof, why is LE not supported? Do you need access to ixp4xx that starts in LE mode? -- Tomasz Chmielewski http://wpkg.org - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On 8 May 2007, at 09:48, Alexey Zaytsev wrote: I was always curious, why do people want to run ixp4xx in LE mode? What are the benefits that overweight the obvious performance degradation? Debian. http://www.debian.org/ports/arm/ Michael-Luke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Alexey Zaytsev schrieb: On 5/8/07, Tomasz Chmielewski [EMAIL PROTECTED] wrote: Michael Jones wrote: +#ifndef __ARMEB__ +#warning Little endian mode not supported +#endif Personally I'm less fussed about WAN / LE support. Anyone with any sense will run ixp4xx boards doing such a specialised network operation as BE. Also, NSLU2-Linux can't test this functionality with our LE setup as we don't have this hardware on-board. You may just want to declare a depends on ARMEB in Kconfig (with or without OR (ARM || BROKEN) ) and have done with it - it's up to you. Christian Hohnstaedt's work did support LE though. Not all ixp4xx boards are by definition doing such a specialised network operation. I was always curious, why do people want to run ixp4xx in LE mode? What are the benefits that overweight the obvious performance degradation? I guess the main reason, at least for me, is that there is only one distro that properly supports LE ARM: Debian. It greatly simplifies management/administration of a higher number of devices, given the fact that Debian also supports other architectures (not just x86/64, sometimes PPC, like most distros do). Not always network performance is to most important factor. -- Tomasz Chmielewski http://wpkg.org - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On 5/8/07, Alexey Zaytsev [EMAIL PROTECTED] wrote: I was always curious, why do people want to run ixp4xx in LE mode? What are the benefits that overweight the obvious performance degradation? Debian on the NSLU2 runs in LE, and it is pretty popular. http://www.linuxdevices.com/news/NS3535328630.html Gordon -- Gordon Farquharson - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Lennert Buytenhek [EMAIL PROTECTED] writes:
+/* Built-in 10/100 Ethernet MAC interfaces */
+static struct mac_plat_info ixdp425_plat_mac[] = {
+{
+.phy= 0,
+.rxq= 3,
+}, {
+.phy= 1,
+.rxq= 4,
+}
+};
As with Christian's driver (I'm feeling like a bit of a broken record
here :-), putting knowledge of which queue to use (which is firmware-
specific) in the _board_ support file is almost certainly wrong.
I would just put the port number in there, and let the ethernet
driver map the port number to the hardware queue number. After all,
the ethernet driver knows which queues the firmware uses, while the
board support code doesn't.
No, quite the opposite. The board code knows its set of hardware
interfaces etc. and can let Ethernet driver use, say, HSS queues.
The driver can't know that.
It would make sense if we had many queues, but it doesn't seem
the case (perhaps the upper queues could be used for some
purposes, but Intel's code doesn't use them either and they
probably know better).
+static inline void set_regbits(u32 bits, u32 __iomem *reg)
+{
+__raw_writel(__raw_readl(reg) | bits, reg);
+}
+static inline void clr_regbits(u32 bits, u32 __iomem *reg)
+{
+__raw_writel(__raw_readl(reg) ~bits, reg);
+}
I generally discourage the use of such wrappers, as it often makes
people forget that the set and clear operations are not atomic, and
it ignores the fact that some of the other bits in the register you
are modifying might have side-effects.
Without them the code in question is hardly readable, I pick the need
to remember about non-atomicity and possible side effects instead :-)
I've outlined the current versions in a separate mail, generally
2 patches are marked v.2 and one v.3.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Tue, May 08, 2007 at 04:31:12PM +0200, Krzysztof Halasa wrote:
+/* Built-in 10/100 Ethernet MAC interfaces */
+static struct mac_plat_info ixdp425_plat_mac[] = {
+ {
+ .phy= 0,
+ .rxq= 3,
+ }, {
+ .phy= 1,
+ .rxq= 4,
+ }
+};
As with Christian's driver (I'm feeling like a bit of a broken record
here :-), putting knowledge of which queue to use (which is firmware-
specific) in the _board_ support file is almost certainly wrong.
I would just put the port number in there, and let the ethernet
driver map the port number to the hardware queue number. After all,
the ethernet driver knows which queues the firmware uses, while the
board support code doesn't.
No, quite the opposite. The board code knows its set of hardware
interfaces etc. and can let Ethernet driver use, say, HSS queues.
The driver can't know that.
You are attacking a point that I did not make.
The board support code knows such things as that the front ethernet
port on the board is connected to the CPU's MII port number #2, but
the board support code does _not_ know that MII port number #2
corresponds to ixp4xx hardware queue #5.
If Intel puts out a firmware update next month, and your ethernet
driver is modified to take advantage of the new features in that
firmware and starts depending on the newer version of that firmware,
we will have to modify every ixp4xx board support file in case the
firmware update modifies the ixp4xx queue numbers in use. The
mapping from hardware ports (MII port #0, MII port #6, HSS port
#42, whatever) to ixp4xx hardware queue numbers (0-63) should _not_
be put in every single ixp4xx board support file.
Even if you only change the
(in board support file)
.rxq= 4,
line to something like this instead:
(in some ixp4xx-specific or driver-specific header file)
#define IXP4XX_MII_PORT_1_RX_QUEUE 4
(in board support file)
.rxq= IXP4XX_MII_PORT_1_RX_QUEUE,
then you have remved this dependency, and then you only have to update
one place if you move to a newer firmware version.
I generally discourage the use of such wrappers, as it often makes
people forget that the set and clear operations are not atomic, and
it ignores the fact that some of the other bits in the register you
are modifying might have side-effects.
Without them the code in question is hardly readable,
You can read Polish, how can you complain about code readability. :-))
*runs*
I pick the need to remember about non-atomicity and possible side
effects instead :-)
Sure, point taken, it's just that the person after you might not
remember..
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Alexey Zaytsev [EMAIL PROTECTED] writes: I was always curious, why do people want to run ixp4xx in LE mode? What are the benefits that overweight the obvious performance degradation? Debian is indeed a valid reason. I wonder if it would be much work to create BE Debian as well. Simple automated process it seems, for most part at least. -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
On Tue, May 08, 2007 at 05:28:21PM +0200, Krzysztof Halasa wrote: I was always curious, why do people want to run ixp4xx in LE mode? What are the benefits that overweight the obvious performance degradation? Debian is indeed a valid reason. I wonder if it would be much work to create BE Debian as well. There _is_ an ARM BE version of Debian. It's not an official port, but it's not maintained any worse than the 'official' LE ARM Debian port is. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Lennert Buytenhek [EMAIL PROTECTED] writes: The board support code knows such things as that the front ethernet port on the board is connected to the CPU's MII port number #2, but the board support code does _not_ know that MII port number #2 corresponds to ixp4xx hardware queue #5. Sure. And I don't want it to know. It has to pick up any available queue for RX, that is. If the board code knows it uses ETH connected to NPE-B and NPE-C, and HSS-0 connected (obviously) to NPE-A, and it wants some crypto functions etc., it can pick a queue which normally belongs to HSS-1. If the code knows the board has both HSS and only NPE-B Ethernet, it can use one of NPE-C Ethernet's queues. It's that simple. The Ethernet (and HSS etc.) driver knows it has to use queue 24 for NPE-B Ethernet's TX and 27 for TX and so on, this is fixed in the firmware so I don't let the board code mess with that. The Ethernet RX queue is different, we can just make something up and tell NPE about that. That's BTW the same thing you would want to do with SRAM - except that the SRAM allocator is technically possible, while making queue assignments needs knowledge about the hardware. If Intel puts out a firmware update next month, and your ethernet driver is modified to take advantage of the new features in that firmware and starts depending on the newer version of that firmware, we will have to modify every ixp4xx board support file in case the firmware update modifies the ixp4xx queue numbers in use. Nope, we just modify Ethernet driver: drivers/net/arm/ixp4xx_eth.c: #define TX_QUEUE(plat) (NPE_ID(port) + 23) #define RXFREE_QUEUE(plat) (NPE_ID(port) + 26) #define TXDONE_QUEUE31 The mapping from hardware ports (MII port #0, MII port #6, HSS port #42, whatever) to ixp4xx hardware queue numbers (0-63) should _not_ be put in every single ixp4xx board support file. I've never considered doing that :-) drivers/net/wan/ixp4xx_hss.c: /* Queue IDs */ #define HSS0_CHL_RXTRIG_QUEUE 12 /* orig size = 32 dwords */ #define HSS0_PKT_RX_QUEUE 13 /* orig size = 32 dwords */ #define HSS0_PKT_TX0_QUEUE 14 /* orig size = 16 dwords */ #define HSS0_PKT_TX1_QUEUE 15 #define HSS0_PKT_TX2_QUEUE 16 #define HSS0_PKT_TX3_QUEUE 17 #define HSS0_PKT_RXFREE0_QUEUE 18 /* orig size = 16 dwords */ #define HSS0_PKT_RXFREE1_QUEUE 19 #define HSS0_PKT_RXFREE2_QUEUE 20 #define HSS0_PKT_RXFREE3_QUEUE 21 #define HSS0_PKT_TXDONE_QUEUE 22 /* orig size = 64 dwords */ #define HSS1_CHL_RXTRIG_QUEUE 10 #define HSS1_PKT_RX_QUEUE 0 #define HSS1_PKT_TX0_QUEUE 5 #define HSS1_PKT_TX1_QUEUE 6 #define HSS1_PKT_TX2_QUEUE 7 #define HSS1_PKT_TX3_QUEUE 8 #define HSS1_PKT_RXFREE0_QUEUE 1 #define HSS1_PKT_RXFREE1_QUEUE 2 #define HSS1_PKT_RXFREE2_QUEUE 3 #define HSS1_PKT_RXFREE3_QUEUE 4 #define HSS1_PKT_TXDONE_QUEUE 9 Without them the code in question is hardly readable, You can read Polish, how can you complain about code readability. :-)) Well, you may have the point, but I also care about others :-) -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Lennert Buytenhek [EMAIL PROTECTED] writes: There _is_ an ARM BE version of Debian. It's not an official port, but it's not maintained any worse than the 'official' LE ARM Debian port is. Hmm... That changes a bit. Perhaps we should forget about that LE thing then, and (at best) put that trivial workaround? -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Krzysztof Halasa schrieb: Lennert Buytenhek [EMAIL PROTECTED] writes: There _is_ an ARM BE version of Debian. It's not an official port, but it's not maintained any worse than the 'official' LE ARM Debian port is. Hmm... That changes a bit. Perhaps we should forget about that LE thing then, and (at best) put that trivial workaround? Does using ixp4xx on LE have any other drawbacks than inferior network performance? And talking about network performance, what numbers are we talking about (LE vs BE; 30% performance hit on LE, more, or less)? -- Tomasz Chmielewski http://wpkg.org - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Tomasz Chmielewski [EMAIL PROTECTED] writes: Does using ixp4xx on LE have any other drawbacks than inferior network performance? More memory is needed, something like max 600 KB for 2 Ethernet ports. And talking about network performance, what numbers are we talking about (LE vs BE; 30% performance hit on LE, more, or less)? Haven't checked yet but I'd expect something like that. -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Why run ixp4xx LE? (Was: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS)
Michael-Luke Jones wrote: On 8 May 2007, at 09:48, Alexey Zaytsev wrote: I was always curious, why do people want to run ixp4xx in LE mode? What are the benefits that overweight the obvious performance degradation? Debian. http://www.debian.org/ports/arm/ And also out-of-kernel drivers for things like webcams, which have been naively written for x86 little endian and have no concept of endian neutrality. In some cases it's just easier to run LE instead of fighting with the driver code. BTW, for the consumer-level IXP42x devices (like the NSLU2) the performance difference is *completely* overwhelmed by slowness in the rest of the system. -- Rod - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS
ACK. I shall presume that the ARM folks will apply these patches. You may tack on an Acked-by: Jeff Garzik [EMAIL PROTECTED] onto the ethernet driver itself. I'll let the ARM folks review the rest. I do agree with the comments in the thread that -- as in your most recent revision -- the non-eth code belongs in arch/arm. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
