* Re: [PATCH 1/5] IrDA: nsc-ircc: ISAPnP support
From: David S. Miller @ 2006-02-19 8:34 UTC (permalink / raw)
To: samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, jt-sDzT885Ts8HQT0dZR+AlfA,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20060213221443.GB31091@irie>
From: Samuel Ortiz <samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Date: Tue, 14 Feb 2006 00:14:43 +0200
> This enables PnP support for the nsc-ircc chipset.
> Since we can't fetch the chipset cfg_base from the PnP layer, we just use
> the PnP information as one more hint when probing the chip.
>
> Signed-off-by: Jean Tourrilhes <jt-sDzT885Ts8HQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Samuel Ortiz <samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Applied, thanks.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply
* Re: [PATCH 2/5] IrDA: nsc-ircc: PM update
From: David S. Miller @ 2006-02-19 8:35 UTC (permalink / raw)
To: samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, jt-sDzT885Ts8HQT0dZR+AlfA,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20060213221509.GC31091@irie>
From: Samuel Ortiz <samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Date: Tue, 14 Feb 2006 00:15:09 +0200
> This patch brings the nsc-ircc code to a more up to date power management
> scheme, following the current device model.
>
> Signed-off-by: Dmitry Torokhov <dtor-JGs/UdohzUI@public.gmane.org>
> Signed-off-by: Rudolf Marek <r.marek-3zVPrsR01WjrBKCeMvbIDA@public.gmane.org>
> Signed-off-by: Samuel Ortiz <samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Applied.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply
* Re: [PATCH 3/5] IrDA: nsc-ircc: support for yet another Thinkpad IrDA chipset
From: David S. Miller @ 2006-02-19 8:35 UTC (permalink / raw)
To: samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, jt-sDzT885Ts8HQT0dZR+AlfA,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20060213221521.GD31091@irie>
From: Samuel Ortiz <samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Date: Tue, 14 Feb 2006 00:15:21 +0200
> This patch simply adds support for a variation of the nsc-ircc PC8739x
> chipset, found in some IBM Thinkpad laptops.
>
> Signed-off-by: Jean Tourrilhes <jt-sDzT885Ts8HQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Samuel Ortiz <samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Applied.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply
* Re: [PATCH 4/5] IrDA: sti/cli removal from EP7211 IrDA driver
From: David S. Miller @ 2006-02-19 8:36 UTC (permalink / raw)
To: samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, jt-sDzT885Ts8HQT0dZR+AlfA,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20060213221538.GE31091@irie>
From: Samuel Ortiz <samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Date: Tue, 14 Feb 2006 00:15:38 +0200
> This patch replaces the deprecated sti/cli routines with the corresponding
> spin_lock ones.
>
> Signed-off-by: David chosrova <david.chosrova-TDf4sKD1mxeHlu7OokbhRg@public.gmane.org>
> Signed-off-by: Samuel Ortiz <samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Applied.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply
* Re: [PATCH 5/5] IrDA: pci_register_driver conversion
From: David S. Miller @ 2006-02-19 8:37 UTC (permalink / raw)
To: samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, jt-sDzT885Ts8HQT0dZR+AlfA,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20060213221548.GF31091@irie>
From: Samuel Ortiz <samuel.ortiz-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Date: Tue, 14 Feb 2006 00:15:48 +0200
> This patch converts 2 IrDA drivers pci_module_init() calls to
> pci_register_driver().
>
> Signed-off-by: Christophe Lucas <clucas-6bugY6I12JBBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Domen Puncer <domen-CvScVCPLwOZg9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Applied.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply
* (usagi-users 03609) IPv6 setsockopt software MTU patch
From: hoerdt @ 2006-02-19 13:47 UTC (permalink / raw)
To: usagi-users; +Cc: davem, netdev, olivier.matz, yoshfuji
In-Reply-To: <20060217.215101.09874309.yoshfuji@linux-ipv6.org>
Hi,
In my precedent mails, i pointed out that IPV6_MTU setsockopt
was ineffective because the field frag_size was not used further
in the ipv6 fragment code of the kernel. You can check out
that this is the case by this simple proof of concept code :
http://clarinet.u-strasbg.fr/~hoerdt/mtu.c
The fix is very simple, it only grab the value of frag_size and
use it in ip6_fragment file, could you please review the patch which
fix that problem at :
http://clarinet.u-strasbg.fr/~hoerdt/ip6_output.c.softfrag.patch
Thanks for the attention,
Hoerdt Mickaël
^ permalink raw reply
* (usagi-users 03610) Re: IPv6 setsockopt software MTU patch
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-02-19 14:13 UTC (permalink / raw)
To: hoerdt; +Cc: usagi-users, davem, netdev, olivier.matz, yoshfuji
In-Reply-To: <20060219134709.GC16304@clarinet.u-strasbg.fr>
In article <20060219134709.GC16304@clarinet.u-strasbg.fr> (at Sun, 19 Feb 2006 14:47:09 +0100), hoerdt@clarinet.u-strasbg.fr says:
> The fix is very simple, it only grab the value of frag_size and
> use it in ip6_fragment file, could you please review the patch which
> fix that problem at :
>
> http://clarinet.u-strasbg.fr/~hoerdt/ip6_output.c.softfrag.patch
Thanks for the patch.
I think even we have np->frag_size, we should consider dst_mtu(&rt->u.dst)
as well. No?
--yoshfuji
^ permalink raw reply
* (usagi-users 03611) Re: IPv6 setsockopt software MTU patch
From: hoerdt @ 2006-02-19 14:54 UTC (permalink / raw)
To: usagi-users; +Cc: davem, netdev, olivier.matz, yoshfuji
In-Reply-To: <20060219.231344.11160682.yoshfuji@linux-ipv6.org>
Yes, Hugo Santos suggested me to use the minimum of both, the new
patch is available there :
http://clarinet.u-strasbg.fr/~hoerdt/ip6_output.c.softfrag.patch2
Thanks,
Hoerdt Mickaël
On Sun, Feb 19, 2006 at 11:13:44PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> In article <20060219134709.GC16304@clarinet.u-strasbg.fr> (at Sun, 19 Feb 2006 14:47:09 +0100), hoerdt@clarinet.u-strasbg.fr says:
>
> > The fix is very simple, it only grab the value of frag_size and
> > use it in ip6_fragment file, could you please review the patch which
> > fix that problem at :
> >
> > http://clarinet.u-strasbg.fr/~hoerdt/ip6_output.c.softfrag.patch
>
> Thanks for the patch.
> I think even we have np->frag_size, we should consider dst_mtu(&rt->u.dst)
> as well. No?
>
> --yoshfuji
>
>
^ permalink raw reply
* (usagi-users 03612) Re: IPv6 setsockopt software MTU patch
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-02-19 16:08 UTC (permalink / raw)
To: hoerdt; +Cc: usagi-users, netdev, olivier.matz, davem, yoshfuji
In-Reply-To: <20060219145413.GD16304@clarinet.u-strasbg.fr>
In article <20060219145413.GD16304@clarinet.u-strasbg.fr> (at Sun, 19 Feb 2006 15:54:13 +0100), hoerdt@clarinet.u-strasbg.fr says:
> Yes, Hugo Santos suggested me to use the minimum of both, the new
> patch is available there :
>
> http://clarinet.u-strasbg.fr/~hoerdt/ip6_output.c.softfrag.patch2
Do you mean like this?
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index efa3e72..3264740 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -494,6 +494,7 @@ static int ip6_fragment(struct sk_buff *
struct net_device *dev;
struct sk_buff *frag;
struct rt6_info *rt = (struct rt6_info*)skb->dst;
+ struct ipv6_pinfo *np = skb->sk ? inet6_sk(skb->sk) : NULL;
struct ipv6hdr *tmp_hdr;
struct frag_hdr *fh;
unsigned int mtu, hlen, left, len;
@@ -506,6 +507,8 @@ static int ip6_fragment(struct sk_buff *
nexthdr = *prevhdr;
mtu = dst_mtu(&rt->u.dst) - hlen - sizeof(struct frag_hdr);
+ if (np && np->frag_size && np->frag_size < dst_mtu(&rt->u.dst))
+ mtu = np->frag_size - hlen - sizeof(struct frag_hdr);
if (skb_shinfo(skb)->frag_list) {
int first_len = skb_pagelen(skb);
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply related
* Re: Merging Skylark's IOC3 patch
From: Martin Michlmayr @ 2006-02-19 21:56 UTC (permalink / raw)
To: Ralf Baechle, netdev; +Cc: linux-mips, Stanislaw Skowronek
In-Reply-To: <20060219211527.GA12848@deprecation.cyrius.com>
* Martin Michlmayr <tbm@cyrius.com> [2006-02-19 21:15]:
> Can you please review and/or merge Skylark's IOC3 patch from
> ftp://ftp.linux-mips.org/pub/linux/mips/people/skylark/linux-mips-2.6.14-ioc3-r26.patch.bz2
>
> From my basic understanding I believe that this patch needs to be split up
> and submitted to different sub-system maintainers.
(netdev@vger.kernel.org, this is only a RFC for now since the main
support patch for IOC3 has not been merged yet.)
From: Stanislaw Skowronek <skylark@linux-mips.org>
[PATCH 3/5] net: Convert the SGI IOC3 Ethernet driver to use IOC3 meta driver
Convert the SGI IOC3 Ethernet driver to use the IOC3 meta driver.
Signed-off-by: Stanislaw Skowronek <skylark@linux-mips.org>
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
---
Kconfig | 2
ioc3-eth.c | 458 +++++++------------------------------------------------------
2 files changed, 55 insertions(+), 405 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 94ad74c..66c340d 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -462,7 +462,7 @@ config MIPS_AU1X00_ENET
config SGI_IOC3_ETH
bool "SGI IOC3 Ethernet"
- depends on NET_ETHERNET && PCI && SGI_IP27
+ depends on NET_ETHERNET && SGI_IOC3
select CRC32
select MII
help
diff --git a/drivers/net/ioc3-eth.c b/drivers/net/ioc3-eth.c
index 9b8295e..8fadae6 100644
--- a/drivers/net/ioc3-eth.c
+++ b/drivers/net/ioc3-eth.c
@@ -5,6 +5,7 @@
*
* Driver for SGI's IOC3 based Ethernet cards as found in the PCI card.
*
+ * Copyright (C) 2005 Stanislaw Skowronek (port to meta-driver)
* Copyright (C) 1999, 2000, 2001, 2003 Ralf Baechle
* Copyright (C) 1995, 1999, 2000, 2001 by Silicon Graphics, Inc.
*
@@ -20,15 +21,13 @@
* o Use prefetching for large packets. What is a good lower limit for
* prefetching?
* o We're probably allocating a bit too much memory.
- * o Use hardware checksums.
- * o Convert to using a IOC3 meta driver.
* o Which PHYs might possibly be attached to the IOC3 in real live,
* which workarounds are required for them? Do we ever have Lucent's?
* o For the 2.5 branch kill the mii-tool ioctls.
*/
#define IOC3_NAME "ioc3-eth"
-#define IOC3_VERSION "2.6.3-3"
+#define IOC3_VERSION "2.6.4-s2"
#include <linux/config.h>
#include <linux/init.h>
@@ -45,11 +44,6 @@
#include <linux/tcp.h>
#include <linux/udp.h>
-#ifdef CONFIG_SERIAL_8250
-#include <linux/serial_core.h>
-#include <linux/serial_8250.h>
-#endif
-
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
#include <linux/ethtool.h>
@@ -61,14 +55,19 @@
#include <asm/io.h>
#include <asm/pgtable.h>
#include <asm/uaccess.h>
+
+#ifdef CONFIG_SGI_IP30
+#include <asm/mach-ip30/addrs.h>
+#else
#include <asm/sn/types.h>
#include <asm/sn/sn0/addrs.h>
#include <asm/sn/sn0/hubni.h>
#include <asm/sn/sn0/hubio.h>
#include <asm/sn/klconfig.h>
-#include <asm/sn/ioc3.h>
#include <asm/sn/sn0/ip27.h>
+#endif
#include <asm/pci/bridge.h>
+#include <linux/ioc3.h>
/*
* 64 RX buffers. This is tunable in the range of 16 <= x < 512. The
@@ -81,6 +80,7 @@
/* Private per NIC data of the driver. */
struct ioc3_private {
+ struct ioc3_driver_data *idd;
struct ioc3 *regs;
unsigned long *rxr; /* pointer to receiver ring */
struct ioc3_etxd *txr;
@@ -149,8 +149,15 @@ static inline unsigned long ioc3_map(voi
return vdev | (0xaUL << PCI64_ATTR_TARG_SHFT) | PCI64_ATTR_PREF |
((unsigned long)ptr & TO_PHYS_MASK);
#else
+#ifdef CONFIG_SGI_IP30
+ vdev <<= 58; /* Shift to PCI64_ATTR_VIRTUAL */
+
+ return vdev | (0x8UL << PCI64_ATTR_TARG_SHFT) | PCI64_ATTR_PREF |
+ ((unsigned long)ptr & TO_PHYS_MASK);
+#else
return virt_to_bus(ptr);
#endif
+#endif
}
/* BEWARE: The IOC3 documentation documents the size of rx buffers as
@@ -226,219 +233,6 @@ static inline unsigned long ioc3_map(voi
#define ioc3_r_midr_w() be32_to_cpu(ioc3->midr_w)
#define ioc3_w_midr_w(v) do { ioc3->midr_w = cpu_to_be32(v); } while (0)
-static inline u32 mcr_pack(u32 pulse, u32 sample)
-{
- return (pulse << 10) | (sample << 2);
-}
-
-static int nic_wait(struct ioc3 *ioc3)
-{
- u32 mcr;
-
- do {
- mcr = ioc3_r_mcr();
- } while (!(mcr & 2));
-
- return mcr & 1;
-}
-
-static int nic_reset(struct ioc3 *ioc3)
-{
- int presence;
-
- ioc3_w_mcr(mcr_pack(500, 65));
- presence = nic_wait(ioc3);
-
- ioc3_w_mcr(mcr_pack(0, 500));
- nic_wait(ioc3);
-
- return presence;
-}
-
-static inline int nic_read_bit(struct ioc3 *ioc3)
-{
- int result;
-
- ioc3_w_mcr(mcr_pack(6, 13));
- result = nic_wait(ioc3);
- ioc3_w_mcr(mcr_pack(0, 100));
- nic_wait(ioc3);
-
- return result;
-}
-
-static inline void nic_write_bit(struct ioc3 *ioc3, int bit)
-{
- if (bit)
- ioc3_w_mcr(mcr_pack(6, 110));
- else
- ioc3_w_mcr(mcr_pack(80, 30));
-
- nic_wait(ioc3);
-}
-
-/*
- * Read a byte from an iButton device
- */
-static u32 nic_read_byte(struct ioc3 *ioc3)
-{
- u32 result = 0;
- int i;
-
- for (i = 0; i < 8; i++)
- result = (result >> 1) | (nic_read_bit(ioc3) << 7);
-
- return result;
-}
-
-/*
- * Write a byte to an iButton device
- */
-static void nic_write_byte(struct ioc3 *ioc3, int byte)
-{
- int i, bit;
-
- for (i = 8; i; i--) {
- bit = byte & 1;
- byte >>= 1;
-
- nic_write_bit(ioc3, bit);
- }
-}
-
-static u64 nic_find(struct ioc3 *ioc3, int *last)
-{
- int a, b, index, disc;
- u64 address = 0;
-
- nic_reset(ioc3);
- /* Search ROM. */
- nic_write_byte(ioc3, 0xf0);
-
- /* Algorithm from ``Book of iButton Standards''. */
- for (index = 0, disc = 0; index < 64; index++) {
- a = nic_read_bit(ioc3);
- b = nic_read_bit(ioc3);
-
- if (a && b) {
- printk("NIC search failed (not fatal).\n");
- *last = 0;
- return 0;
- }
-
- if (!a && !b) {
- if (index == *last) {
- address |= 1UL << index;
- } else if (index > *last) {
- address &= ~(1UL << index);
- disc = index;
- } else if ((address & (1UL << index)) == 0)
- disc = index;
- nic_write_bit(ioc3, address & (1UL << index));
- continue;
- } else {
- if (a)
- address |= 1UL << index;
- else
- address &= ~(1UL << index);
- nic_write_bit(ioc3, a);
- continue;
- }
- }
-
- *last = disc;
-
- return address;
-}
-
-static int nic_init(struct ioc3 *ioc3)
-{
- const char *type;
- u8 crc;
- u8 serial[6];
- int save = 0, i;
-
- type = "unknown";
-
- while (1) {
- u64 reg;
- reg = nic_find(ioc3, &save);
-
- switch (reg & 0xff) {
- case 0x91:
- type = "DS1981U";
- break;
- default:
- if (save == 0) {
- /* Let the caller try again. */
- return -1;
- }
- continue;
- }
-
- nic_reset(ioc3);
-
- /* Match ROM. */
- nic_write_byte(ioc3, 0x55);
- for (i = 0; i < 8; i++)
- nic_write_byte(ioc3, (reg >> (i << 3)) & 0xff);
-
- reg >>= 8; /* Shift out type. */
- for (i = 0; i < 6; i++) {
- serial[i] = reg & 0xff;
- reg >>= 8;
- }
- crc = reg & 0xff;
- break;
- }
-
- printk("Found %s NIC", type);
- if (type != "unknown") {
- printk (" registration number %02x:%02x:%02x:%02x:%02x:%02x,"
- " CRC %02x", serial[0], serial[1], serial[2],
- serial[3], serial[4], serial[5], crc);
- }
- printk(".\n");
-
- return 0;
-}
-
-/*
- * Read the NIC (Number-In-a-Can) device used to store the MAC address on
- * SN0 / SN00 nodeboards and PCI cards.
- */
-static void ioc3_get_eaddr_nic(struct ioc3_private *ip)
-{
- struct ioc3 *ioc3 = ip->regs;
- u8 nic[14];
- int tries = 2; /* There may be some problem with the battery? */
- int i;
-
- ioc3_w_gpcr_s(1 << 21);
-
- while (tries--) {
- if (!nic_init(ioc3))
- break;
- udelay(500);
- }
-
- if (tries < 0) {
- printk("Failed to read MAC address\n");
- return;
- }
-
- /* Read Memory. */
- nic_write_byte(ioc3, 0xf0);
- nic_write_byte(ioc3, 0x00);
- nic_write_byte(ioc3, 0x00);
-
- for (i = 13; i >= 0; i--)
- nic[i] = nic_read_byte(ioc3);
-
- for (i = 2; i < 8; i++)
- priv_netdev(ip)->dev_addr[i - 2] = nic[i];
-}
-
/*
* Ok, this is hosed by design. It's necessary to know what machine the
* NIC is in in order to know how to read the NIC address. We also have
@@ -446,12 +240,16 @@ static void ioc3_get_eaddr_nic(struct io
*/
static void ioc3_get_eaddr(struct ioc3_private *ip)
{
- int i;
+ int i,nz=0;
-
- ioc3_get_eaddr_nic(ip);
+ for(i=0;i<6;i++)
+ nz |= (priv_netdev(ip)->dev_addr[i] = ip->idd->nic_mac[i]);
printk("Ethernet address is ");
+ if(!nz) {
+ printk("unreadable.\n");
+ return;
+ }
for (i = 0; i < 6; i++) {
printk("%02x", priv_netdev(ip)->dev_addr[i]);
if (i < 5)
@@ -750,9 +548,9 @@ static void ioc3_error(struct ioc3_priva
/* The interrupt handler does all of the Rx thread work and cleans up
after the Tx thread. */
-static irqreturn_t ioc3_interrupt(int irq, void *_dev, struct pt_regs *regs)
+static int ioc3eth_intr(struct ioc3_submodule *is, struct ioc3_driver_data *idd, unsigned int irq, struct pt_regs *regs)
{
- struct net_device *dev = (struct net_device *)_dev;
+ struct net_device *dev = (struct net_device *)(idd->data[is->id]);
struct ioc3_private *ip = netdev_priv(dev);
struct ioc3 *ioc3 = ip->regs;
const u32 enabled = EISR_RXTIMERINT | EISR_RXOFLO | EISR_RXBUFOFLO |
@@ -773,7 +571,7 @@ static irqreturn_t ioc3_interrupt(int ir
if (eisr & EISR_TXEXPLICIT)
ioc3_tx(ip);
- return IRQ_HANDLED;
+ return 0;
}
static inline void ioc3_setup_duplex(struct ioc3_private *ip)
@@ -840,6 +638,7 @@ static int ioc3_mii_init(struct ioc3_pri
ip->ioc3_timer.expires = jiffies + (12 * HZ)/10; /* 1.2 sec. */
ip->ioc3_timer.data = (unsigned long) ip;
ip->ioc3_timer.function = &ioc3_timer;
+
add_timer(&ip->ioc3_timer);
out:
@@ -1026,7 +825,7 @@ static void ioc3_init(struct net_device
(void) ioc3_r_emcr();
/* Misc registers */
-#ifdef CONFIG_SGI_IP27
+#if (defined CONFIG_SGI_IP27) || (defined CONFIG_SGI_IP30)
ioc3_w_erbar(PCI64_ATTR_BAR >> 32); /* Barrier on last store */
#else
ioc3_w_erbar(0); /* Let PCI API get it right */
@@ -1063,12 +862,6 @@ static int ioc3_open(struct net_device *
{
struct ioc3_private *ip = netdev_priv(dev);
- if (request_irq(dev->irq, ioc3_interrupt, SA_SHIRQ, ioc3_str, dev)) {
- printk(KERN_ERR "%s: Can't get irq %d\n", dev->name, dev->irq);
-
- return -EAGAIN;
- }
-
ip->ehar_h = 0;
ip->ehar_l = 0;
ioc3_init(dev);
@@ -1086,105 +879,12 @@ static int ioc3_close(struct net_device
netif_stop_queue(dev);
ioc3_stop(ip);
- free_irq(dev->irq, dev);
ioc3_free_rings(ip);
return 0;
}
-/*
- * MENET cards have four IOC3 chips, which are attached to two sets of
- * PCI slot resources each: the primary connections are on slots
- * 0..3 and the secondaries are on 4..7
- *
- * All four ethernets are brought out to connectors; six serial ports
- * (a pair from each of the first three IOC3s) are brought out to
- * MiniDINs; all other subdevices are left swinging in the wind, leave
- * them disabled.
- */
-static inline int ioc3_is_menet(struct pci_dev *pdev)
-{
- struct pci_dev *dev;
-
- return pdev->bus->parent == NULL
- && (dev = pci_find_slot(pdev->bus->number, PCI_DEVFN(0, 0)))
- && dev->vendor == PCI_VENDOR_ID_SGI
- && dev->device == PCI_DEVICE_ID_SGI_IOC3
- && (dev = pci_find_slot(pdev->bus->number, PCI_DEVFN(1, 0)))
- && dev->vendor == PCI_VENDOR_ID_SGI
- && dev->device == PCI_DEVICE_ID_SGI_IOC3
- && (dev = pci_find_slot(pdev->bus->number, PCI_DEVFN(2, 0)))
- && dev->vendor == PCI_VENDOR_ID_SGI
- && dev->device == PCI_DEVICE_ID_SGI_IOC3;
-}
-
-#ifdef CONFIG_SERIAL_8250
-/*
- * Note about serial ports and consoles:
- * For console output, everyone uses the IOC3 UARTA (offset 0x178)
- * connected to the master node (look in ip27_setup_console() and
- * ip27prom_console_write()).
- *
- * For serial (/dev/ttyS0 etc), we can not have hardcoded serial port
- * addresses on a partitioned machine. Since we currently use the ioc3
- * serial ports, we use dynamic serial port discovery that the serial.c
- * driver uses for pci/pnp ports (there is an entry for the SGI ioc3
- * boards in pci_boards[]). Unfortunately, UARTA's pio address is greater
- * than UARTB's, although UARTA on o200s has traditionally been known as
- * port 0. So, we just use one serial port from each ioc3 (since the
- * serial driver adds addresses to get to higher ports).
- *
- * The first one to do a register_console becomes the preferred console
- * (if there is no kernel command line console= directive). /dev/console
- * (ie 5, 1) is then "aliased" into the device number returned by the
- * "device" routine referred to in this console structure
- * (ip27prom_console_dev).
- *
- * Also look in ip27-pci.c:pci_fixup_ioc3() for some comments on working
- * around ioc3 oddities in this respect.
- *
- * The IOC3 serials use a 22MHz clock rate with an additional divider by 3.
- */
-
-static void __devinit ioc3_serial_probe(struct pci_dev *pdev, struct ioc3 *ioc3)
-{
- struct uart_port port;
-
- /*
- * We need to recognice and treat the fourth MENET serial as it
- * does not have an SuperIO chip attached to it, therefore attempting
- * to access it will result in bus errors. We call something an
- * MENET if PCI slot 0, 1, 2 and 3 of a master PCI bus all have an IOC3
- * in it. This is paranoid but we want to avoid blowing up on a
- * showhorn PCI box that happens to have 4 IOC3 cards in it so it's
- * not paranoid enough ...
- */
- if (ioc3_is_menet(pdev) && PCI_SLOT(pdev->devfn) == 3)
- return;
-
- /*
- * Register to interrupt zero because we share the interrupt with
- * the serial driver which we don't properly support yet.
- *
- * Can't use UPF_IOREMAP as the whole of IOC3 resources have already
- * been registered.
- */
- memset(&port, 0, sizeof(port));
- port.irq = 0;
- port.flags = UPF_SKIP_TEST | UPF_BOOT_AUTOCONF;
- port.iotype = UPIO_MEM;
- port.regshift = 0;
- port.uartclk = 22000000 / 3;
-
- port.membase = (unsigned char *) &ioc3->sregs.uarta;
- serial8250_register_port(&port);
-
- port.membase = (unsigned char *) &ioc3->sregs.uartb;
- serial8250_register_port(&port);
-}
-#endif
-
-static int ioc3_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+static int ioc3eth_probe(struct ioc3_submodule *is, struct ioc3_driver_data *idd)
{
unsigned int sw_physid1, sw_physid2;
struct net_device *dev = NULL;
@@ -1194,63 +894,29 @@ static int ioc3_probe(struct pci_dev *pd
u32 vendor, model, rev;
int err, pci_using_dac;
- /* Configure DMA attributes. */
- err = pci_set_dma_mask(pdev, 0xffffffffffffffffULL);
- if (!err) {
- pci_using_dac = 1;
- err = pci_set_consistent_dma_mask(pdev, 0xffffffffffffffffULL);
- if (err < 0) {
- printk(KERN_ERR "%s: Unable to obtain 64 bit DMA "
- "for consistent allocations\n", pci_name(pdev));
- goto out;
- }
- } else {
- err = pci_set_dma_mask(pdev, 0xffffffffULL);
- if (err) {
- printk(KERN_ERR "%s: No usable DMA configuration, "
- "aborting.\n", pci_name(pdev));
- goto out;
- }
- pci_using_dac = 0;
- }
-
- if (pci_enable_device(pdev))
- return -ENODEV;
+ /* check for board type */
+ if(idd->class == IOC3_CLASS_SERIAL)
+ return 1;
dev = alloc_etherdev(sizeof(struct ioc3_private));
if (!dev) {
err = -ENOMEM;
goto out_disable;
}
+ idd->data[is->id] = dev;
- if (pci_using_dac)
- dev->features |= NETIF_F_HIGHDMA;
-
- err = pci_request_regions(pdev, "ioc3");
- if (err)
- goto out_free;
+ /* assume we always have DAC */
+ dev->features |= NETIF_F_HIGHDMA;
SET_MODULE_OWNER(dev);
- SET_NETDEV_DEV(dev, &pdev->dev);
+ SET_NETDEV_DEV(dev, &(idd->pdev->dev));
ip = netdev_priv(dev);
- dev->irq = pdev->irq;
+ dev->irq = idd->pdev->irq;
- ioc3_base = pci_resource_start(pdev, 0);
- ioc3_size = pci_resource_len(pdev, 0);
- ioc3 = (struct ioc3 *) ioremap(ioc3_base, ioc3_size);
- if (!ioc3) {
- printk(KERN_CRIT "ioc3eth(%s): ioremap failed, goodbye.\n",
- pci_name(pdev));
- err = -ENOMEM;
- goto out_res;
- }
- ip->regs = ioc3;
-
-#ifdef CONFIG_SERIAL_8250
- ioc3_serial_probe(pdev, ioc3);
-#endif
+ ip->idd = idd;
+ ip->regs = ioc3 = idd->vma;
spin_lock_init(&ip->ioc3_lock);
init_timer(&ip->ioc3_timer);
@@ -1258,7 +924,7 @@ static int ioc3_probe(struct pci_dev *pd
ioc3_stop(ip);
ioc3_init(dev);
- ip->pdev = pdev;
+ ip->pdev = idd->pdev;
ip->mii.phy_id_mask = 0x1f;
ip->mii.reg_num_mask = 0x1f;
@@ -1270,7 +936,7 @@ static int ioc3_probe(struct pci_dev *pd
if (ip->mii.phy_id == -1) {
printk(KERN_CRIT "ioc3-eth(%s): Didn't find a PHY, goodbye.\n",
- pci_name(pdev));
+ pci_name(idd->pdev));
err = -ENODEV;
goto out_stop;
}
@@ -1316,56 +982,40 @@ static int ioc3_probe(struct pci_dev *pd
out_stop:
ioc3_stop(ip);
ioc3_free_rings(ip);
-out_res:
- pci_release_regions(pdev);
-out_free:
free_netdev(dev);
out_disable:
- /*
- * We should call pci_disable_device(pdev); here if the IOC3 wasn't
- * such a weird device ...
- */
out:
return err;
}
-static void __devexit ioc3_remove_one (struct pci_dev *pdev)
+static int ioc3eth_remove(struct ioc3_submodule *is, struct ioc3_driver_data *idd)
{
- struct net_device *dev = pci_get_drvdata(pdev);
+ struct net_device *dev = idd->data[is->id];
struct ioc3_private *ip = netdev_priv(dev);
- struct ioc3 *ioc3 = ip->regs;
unregister_netdev(dev);
- iounmap(ioc3);
- pci_release_regions(pdev);
free_netdev(dev);
- /*
- * We should call pci_disable_device(pdev); here if the IOC3 wasn't
- * such a weird device ...
- */
+ return 0;
}
-static struct pci_device_id ioc3_pci_tbl[] = {
- { PCI_VENDOR_ID_SGI, PCI_DEVICE_ID_SGI_IOC3, PCI_ANY_ID, PCI_ANY_ID },
- { 0 }
-};
-MODULE_DEVICE_TABLE(pci, ioc3_pci_tbl);
-
-static struct pci_driver ioc3_driver = {
- .name = "ioc3-eth",
- .id_table = ioc3_pci_tbl,
- .probe = ioc3_probe,
- .remove = __devexit_p(ioc3_remove_one),
+static struct ioc3_submodule ioc3eth_submodule = {
+ .name = "ethernet",
+ .probe = ioc3eth_probe,
+ .remove = ioc3eth_remove,
+ .ethernet = 1,
+ .intr = ioc3eth_intr,
+ .owner = THIS_MODULE,
};
static int __init ioc3_init_module(void)
{
- return pci_register_driver(&ioc3_driver);
+ ioc3_register_submodule(&ioc3eth_submodule);
+ return 0;
}
static void __exit ioc3_cleanup_module(void)
{
- pci_unregister_driver(&ioc3_driver);
+ ioc3_unregister_submodule(&ioc3eth_submodule);
}
static int ioc3_start_xmit(struct sk_buff *skb, struct net_device *dev)
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply related
* Re: Diff between Linus' and linux-mips git: declance
From: Martin Michlmayr @ 2006-02-20 0:17 UTC (permalink / raw)
To: netdev, linux-mips
In-Reply-To: <20060220000141.GX10266@deprecation.cyrius.com>
Remove delta between Linus' and linux-mips git trees in declance
There are two changes between the Linus' and linux-mips git trees
regarding the declaner driver. The first change is certainly correct
(as it is consistent with the rest of the file) and should be applied
to mainline; the other change seems correct too.
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
--- linux-2.6.16-rc4/drivers/net/declance.c 2006-02-19 20:09:07.000000000 +0000
+++ mips-2.6.16-rc4/drivers/net/declance.c 2006-02-19 20:15:22.000000000 +0000
@@ -704,8 +704,8 @@
return IRQ_HANDLED;
}
-static irqreturn_t
-lance_interrupt(const int irq, void *dev_id, struct pt_regs *regs)
+static irqreturn_t lance_interrupt(const int irq, void *dev_id,
+ struct pt_regs *regs)
{
struct net_device *dev = (struct net_device *) dev_id;
struct lance_private *lp = netdev_priv(dev);
@@ -1255,7 +1255,7 @@
return 0;
err_out_free_dev:
- kfree(dev);
+ free_netdev(dev);
err_out:
return ret;
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply
* [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: Martin Michlmayr @ 2006-02-20 1:01 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: John Bowler
From: John Bowler <jbowler@acm.org>
Some Ethernet hardware implementations have no built-in storage for
allocated MAC values - an example is the Intel IXP420 chip which has
support for Ethernet but no defined way of storing allocated MAC values.
With such hardware different board level implementations store the
allocated MAC (or MACs) in different ways. Rather than put board level
code into a specific Ethernet driver this driver provides a generally
accessible repository for the MACs which can be written by board level
code and read by the driver.
The implementation also allows user level programs to access the MAC
information in /proc/net/maclist. This is useful as it allows user space
code to use the MAC if it is not used by a built-in driver.
This driver has been used for several months on various IXP420 based
platforms within the NSLU2-Linux project, including the Linksys NSLU2.
A sample implementation of the use of maclist is sent as patch 2. This
one is for the Linksys NSLU2, but several more patches for other IXP420
based platforms are available.
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Rod Whitby <rod@whitby.id.au>
---
drivers/net/Kconfig | 15 ++
drivers/net/Makefile | 1
drivers/net/maclist.c | 314 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/net/maclist.h | 23 +++
4 files changed, 353 insertions(+)
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-nslu2/include/net/maclist.h 2006-02-06 22:35:23.000000000 +0100
@@ -0,0 +1,23 @@
+#ifndef _MACLIST_H
+#define _MACLIST_H 1
+/*
+ * Interfaces to the MAC repository
+ */
+/*
+ * Add a single entry, returns 0 on success else an error
+ * code. Must *not* be called from an interrupt handler.
+ */
+extern int maclist_add(const u8 id_to_add[6]);
+
+/*
+ * Return the current entry count (valid in any context).
+ */
+extern int maclist_count(void);
+
+/*
+ * Return the ID from the n'th entry (valid in any context),
+ * returns 0 on success, -EINVAL if 'n' is out of range.
+ */
+extern int maclist_read(u8 (*buffer_for_id)[6], int index_of_id_to_return);
+
+#endif /*_MACLIST_H*/
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-nslu2/drivers/net/maclist.c 2006-02-06 22:35:23.000000000 +0100
@@ -0,0 +1,314 @@
+/*
+ * drivers/net/maclist.c
+ *
+ * a simple driver to remember ethernet MAC values
+ *
+ * Some Ethernet hardware implementations have no built-in
+ * storage for allocated MAC values - an example is the Intel
+ * IXP420 chip which has support for Ethernet but no defined
+ * way of storing allocated MAC values. With such hardware
+ * different board level implementations store the allocated
+ * MAC (or MACs) in different ways. Rather than put board
+ * level code into a specific Ethernet driver this driver
+ * provides a generally accessible repository for the MACs
+ * which can be written by board level code and read by the
+ * driver.
+ *
+ * The implementation also allows user level programs to
+ * access the MAC information in /proc/net/maclist. This is
+ * useful as it allows user space code to use the MAC if it
+ * is not used by a built-in driver.
+ *
+ * Copyright (C) 2005 John Bowler
+ * Author: John Bowler <jbowler@acm.org>
+ * Maintainers: http://www.nslu2-linux.org/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * External interfaces:
+ * Interfaces to linux kernel (and modules)
+ * maclist_add: add a single MAC
+ * maclist_count: total number of MACs stored
+ * maclist_read: read a MAC 0..(maclist_count-1)
+ */
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/etherdevice.h>
+#include <linux/proc_fs.h>
+#include <linux/errno.h>
+
+#include <net/maclist.h>
+
+#define MACLIST_NAME "maclist"
+
+MODULE_AUTHOR("John Bowler <jbowler@acm.org>");
+MODULE_DESCRIPTION("MAC list repository");
+MODULE_LICENSE("GPL");
+
+typedef struct maclist_entry {
+ struct maclist_entry *next; /* Linked list, first first */
+ u8 id[6]; /* 6 byte Ethernet MAC */
+} maclist_entry_t;
+
+/* Access to this list is possible at any time - entries in
+ * the list are never destroyed. Modification of the list is
+ * safe only from the init code (i.e. modification must be
+ * single threaded), but read from an interrupt at the same
+ * time is possible and safe.
+ */
+static maclist_entry_t *maclist_list = 0;
+
+/*
+ * External interfaces.
+ *
+ * Add a single entry, returns 0 on success else an error
+ * code. Must be single threaded.
+ */
+int maclist_add(const u8 new_id[6]) {
+ maclist_entry_t *new_entry, **tail;
+
+ if (new_id == 0 || !is_valid_ether_addr(new_id)) {
+ printk(KERN_ERR MACLIST_NAME ": invalid ethernet address\n");
+ return -EINVAL;
+ }
+ new_entry = kmalloc(sizeof *new_entry, GFP_KERNEL);
+ if (new_entry == 0)
+ return -ENOMEM;
+ new_entry->next = 0;
+ memcpy(new_entry->id, new_id, sizeof new_entry->id);
+
+ tail = &maclist_list;
+ while (*tail != 0)
+ tail = &(*tail)->next;
+ *tail = new_entry;
+ return 0;
+}
+EXPORT_SYMBOL(maclist_add);
+
+/*
+ * Return the current entry count (valid in any context).
+ */
+int maclist_count(void) {
+ maclist_entry_t *tail = maclist_list;
+ int count = 0;
+
+ while (tail != 0) {
+ tail = tail->next;
+ ++count;
+ }
+
+ return count;
+}
+EXPORT_SYMBOL(maclist_count);
+
+/*
+ * Return the ID from the n'th entry (valid in any context),
+ * returns 0 on success, -EINVAL if 'n' is out of range.
+ */
+int maclist_read(u8 (*id)[6], int n) {
+ maclist_entry_t *entry = maclist_list;
+
+ while (n > 0 && entry != 0) {
+ --n;
+ entry = entry->next;
+ }
+
+ if (n == 0 && entry != 0) {
+ memcpy(id, entry->id, sizeof *id);
+ return 0;
+ }
+
+ printk(KERN_ERR MACLIST_NAME ": id does not exist\n");
+ return -EINVAL;
+}
+EXPORT_SYMBOL(maclist_read);
+
+/*
+ * Parameter parsing. The option string is a list of MAC
+ * addresses, comma separated. (The parsing really should
+ * be somewhere central...)
+ */
+static int __init maclist_setup(char *param) {
+ int bytes = 0, seen_a_digit = 0;
+ u8 id[6];
+
+ memset(id, 0, sizeof id);
+
+ if (param) do {
+ int digit = -1;
+ switch (*param) {
+ case '0': digit = 0; break;
+ case '1': digit = 1; break;
+ case '2': digit = 2; break;
+ case '3': digit = 3; break;
+ case '4': digit = 4; break;
+ case '5': digit = 5; break;
+ case '6': digit = 6; break;
+ case '7': digit = 7; break;
+ case '8': digit = 8; break;
+ case '9': digit = 9; break;
+ case 'a': case 'A': digit = 10; break;
+ case 'b': case 'B': digit = 11; break;
+ case 'c': case 'C': digit = 12; break;
+ case 'd': case 'D': digit = 13; break;
+ case 'e': case 'E': digit = 14; break;
+ case 'f': case 'F': digit = 15; break;
+ case ':':
+ if (seen_a_digit)
+ bytes = (bytes+1) & ~1;
+ else
+ bytes += 2; /* i.e. ff::ff is ff:00:ff */
+ seen_a_digit = 0;
+ break;
+ case 0:
+ if (bytes == 0) /* nothing new seen so far */
+ return 0;
+ /*fall through*/
+ case ',': case ';':
+ if (bytes > 0)
+ bytes = 12; /* i.e. all trailing bytes 0 */
+ break;
+ default:
+ printk(KERN_ERR MACLIST_NAME ": invalid character <%c[%d]>\n",
+ *param, *param);
+ return -EINVAL;
+ }
+
+ if (digit >= 0) {
+ id[bytes>>1] = (id[bytes>>1] << 4) + digit; break;
+ ++bytes;
+ seen_a_digit = 1;
+ }
+
+ if (bytes >= 12) {
+ int rc = maclist_add(id);
+ if (rc)
+ return rc;
+ bytes = 0;
+ seen_a_digit = 0;
+ memset(id, 0, sizeof id);
+ if (*param == 0)
+ return 0;
+ }
+ ++param;
+ } while (1);
+
+ return 0;
+}
+
+/*
+ * procfs support, if compiled in.
+ */
+#ifdef CONFIG_PROC_FS
+/*
+ * Character device read
+ */
+static int maclist_getchar(off_t n) {
+ static char xdigit[16] = "0123456789abcdef";
+ maclist_entry_t *head = maclist_list;
+ int b;
+
+ do {
+ if (head == 0)
+ return -1;
+ if (n < 18)
+ break;
+ head = head->next;
+ n -= 18;
+ } while (1);
+
+ if (n == 17)
+ return '\n';
+
+ b = n/3;
+ switch (n - b*3) {
+ case 0: return xdigit[head->id[b] >> 4];
+ case 1: return xdigit[head->id[b] & 0xf];
+ default: return ':';
+ }
+}
+
+/*
+ * The extensively undocumented proc_read_t callback is implemented here.
+ * Go look in fs/proc/generic.c:
+ *
+ * Prototype:
+ * int f(char *buffer, char **start, off_t offset,
+ * int count, int *peof, void *dat)
+ *
+ * Assume that the buffer is "count" bytes in size.
+ *
+ * 2) Set *start = an address within the buffer.
+ * Put the data of the requested offset at *start.
+ * Return the number of bytes of data placed there.
+ * If this number is greater than zero and you
+ * didn't signal eof and the reader is prepared to
+ * take more data you will be called again with the
+ * requested offset advanced by the number of bytes
+ * absorbed.
+ */
+static int maclist_proc_read(char *buffer, char **start, off_t offset,
+ int count, int *peof, void *dat) {
+ int total;
+
+ *start = buffer;
+ total = 0;
+
+ while (total < count) {
+ int ch = maclist_getchar(offset++);
+ if (ch == -1) {
+ *peof = 1;
+ break;
+ }
+ *buffer++ = ch;
+ ++total;
+ }
+
+ return total;
+}
+#endif
+
+/*
+ * Finally, the init/exit functions.
+ */
+static void __exit maclist_exit(void)
+{
+ maclist_entry_t *list;
+
+ remove_proc_entry(MACLIST_NAME, proc_net);
+
+ list = maclist_list;
+ maclist_list = 0;
+
+ while (list != 0) {
+ maclist_entry_t *head = list;
+ list = head->next;
+ kfree(head);
+ }
+}
+
+#ifdef MODULE
+static char ids[256];
+module_param_string(ids, ids, sizeof ids, 0);
+MODULE_PARM_DESC(ids, "comma separated list of MAC ids\n");
+#else
+__setup("maclist_ids=", maclist_setup);
+#endif
+
+static int __init maclist_init(void)
+{
+# ifdef MODULE
+ if (ids[0])
+ maclist_setup(ids);
+# endif
+
+ /* Ignore failure, the module will still work. */
+ (void)create_proc_read_entry(MACLIST_NAME, S_IRUGO, proc_net, maclist_proc_read, NULL);
+
+ return 0;
+}
+
+module_init(maclist_init);
+module_exit(maclist_exit);
--- linux-nslu2.orig/drivers/net/Makefile 2006-02-06 22:35:18.000000000 +0100
+++ linux-nslu2/drivers/net/Makefile 2006-02-06 22:35:23.000000000 +0100
@@ -74,6 +74,7 @@ obj-$(CONFIG_RIONET) += rionet.o
# end link order section
#
+obj-$(CONFIG_MACLIST) += maclist.o
obj-$(CONFIG_MII) += mii.o
obj-$(CONFIG_PHYLIB) += phy/
--- linux-nslu2.orig/drivers/net/Kconfig 2006-02-06 22:35:18.000000000 +0100
+++ linux-nslu2/drivers/net/Kconfig 2006-02-06 22:35:23.000000000 +0100
@@ -180,6 +180,21 @@ config NET_ETHERNET
kernel: saying N will just cause the configurator to skip all
the questions about Ethernet network cards. If unsure, say N.
+config MACLIST
+ tristate "Ethernet MAC repository"
+ depends on NET_ETHERNET
+ help
+ Some ethernet controllers have no built-in way of obtaining an
+ appropriate Ethernet MAC address. Such controllers have to be
+ initialised in a board-specific way, depending on how the allocated
+ MAC is stored. The MAC repository provides a set of APIs and a
+ proc entry (/proc/net/maclist) to store MAC values from the board
+ so that such drivers can obtain a MAC address without board-specific
+ code. You do not need to enable this device - it will be selected
+ automatically by any device which requires it. It is only useful
+ to enable it manually when building a device driver independently
+ of the kernel build.
+
config MII
tristate "Generic Media Independent Interface device support"
depends on NET_ETHERNET
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply
* [RFC] [PATCH 2/2] Driver to remember ethernet MAC values: NSLU2 support
From: Martin Michlmayr @ 2006-02-20 1:01 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: John Bowler
From: John Bowler <jbowler@acm.org>
Implement maclist support for the Linksys NSLU2. The MAC address is read
from the RedBoot partition in flash.
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Rod Whitby <rod@whitby.id.au>
--
arch/arm/mach-ixp4xx/Kconfig | 4 +--
arch/arm/mach-ixp4xx/nslu2-setup.c | 39 +++++++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+), 2 deletions(-)
--- linux-nslu2.orig/arch/arm/mach-ixp4xx/nslu2-setup.c 2006-02-06 22:34:55.000000000 +0100
+++ linux-nslu2/arch/arm/mach-ixp4xx/nslu2-setup.c 2006-02-06 22:35:31.000000000 +0100
@@ -16,11 +16,14 @@
#include <linux/kernel.h>
#include <linux/serial.h>
#include <linux/serial_8250.h>
+#include <linux/mtd/mtd.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
#include <asm/mach/flash.h>
+#include <net/maclist.h>
+
static struct flash_platform_data nslu2_flash_data = {
.map_name = "cfi_probe",
.width = 2,
@@ -117,6 +120,37 @@ static void nslu2_power_off(void)
gpio_line_set(NSLU2_PO_GPIO, IXP4XX_GPIO_HIGH);
}
+/*
+ * When the RedBoot partition is added the MAC address is read from
+ * it.
+ */
+static void nslu2_flash_add(struct mtd_info *mtd) {
+ if (strcmp(mtd->name, "RedBoot") == 0) {
+ size_t retlen;
+ u_char mac[6];
+
+ /* The MAC is at a known offset... */
+ if (mtd->read(mtd, 0x3FFB0, 6, &retlen, mac) == 0 && retlen == 6) {
+ printk(KERN_INFO "NSLU2 MAC: %.2x:%.2x:%.2x:%.2x:%.2x:%.2x\n",
+ mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);
+ maclist_add(mac);
+ } else {
+ printk(KERN_ERR "NSLU2 MAC: read failed\n");
+ }
+ }
+}
+
+/*
+ * Nothing to do on remove at present.
+ */
+static void nslu2_flash_remove(struct mtd_info *mtd) {
+}
+
+static struct mtd_notifier nslu2_flash_notifier = {
+ .add = nslu2_flash_add,
+ .remove = nslu2_flash_remove,
+};
+
static void __init nslu2_init(void)
{
/* The NSLU2 has a 33MHz crystal on board - 1.01% different
@@ -124,6 +158,11 @@ static void __init nslu2_init(void)
*/
ixp4xx_set_board_tick_rate(66000000);
+ /* The flash has an ethernet MAC embedded in it which we need,
+ * that is all this notifier does.
+ */
+ register_mtd_user(&nslu2_flash_notifier);
+
ixp4xx_sys_init();
pm_power_off = nslu2_power_off;
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: Adrian Bunk @ 2006-02-20 1:47 UTC (permalink / raw)
To: Martin Michlmayr; +Cc: linux-kernel, netdev, John Bowler
In-Reply-To: <20060220010113.GA19309@deprecation.cyrius.com>
On Mon, Feb 20, 2006 at 01:01:13AM +0000, Martin Michlmayr wrote:
> From: John Bowler <jbowler@acm.org>
>
> Some Ethernet hardware implementations have no built-in storage for
> allocated MAC values - an example is the Intel IXP420 chip which has
> support for Ethernet but no defined way of storing allocated MAC values.
> With such hardware different board level implementations store the
> allocated MAC (or MACs) in different ways. Rather than put board level
> code into a specific Ethernet driver this driver provides a generally
> accessible repository for the MACs which can be written by board level
> code and read by the driver.
>
> The implementation also allows user level programs to access the MAC
> information in /proc/net/maclist. This is useful as it allows user space
> code to use the MAC if it is not used by a built-in driver.
>
> This driver has been used for several months on various IXP420 based
> platforms within the NSLU2-Linux project, including the Linksys NSLU2.
> A sample implementation of the use of maclist is sent as patch 2. This
> one is for the Linksys NSLU2, but several more patches for other IXP420
> based platforms are available.
>...
Silly question:
Why can't this be implemented in user space using the SIOCSIFHWADDR
ioctl?
> Martin Michlmayr
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: Alessandro Zummo @ 2006-02-20 2:01 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Martin Michlmayr, linux-kernel, netdev, John Bowler
In-Reply-To: <20060220014735.GD4971@stusta.de>
On Mon, 20 Feb 2006 02:47:35 +0100
Adrian Bunk <bunk@stusta.de> wrote:
> > Some Ethernet hardware implementations have no built-in storage for
> > allocated MAC values - an example is the Intel IXP420 chip which has
> > support for Ethernet but no defined way of storing allocated MAC values.
> > With such hardware different board level implementations store the
> > allocated MAC (or MACs) in different ways. Rather than put board level
> > c
> Silly question:
>
> Why can't this be implemented in user space using the SIOCSIFHWADDR
> ioctl?
Because sometimes you need to have networking available
well before userspace.
(netconsole, root over nfs, ...)
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
http://www.towertech.it
^ permalink raw reply
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: Adrian Bunk @ 2006-02-20 2:39 UTC (permalink / raw)
To: Alessandro Zummo; +Cc: Martin Michlmayr, linux-kernel, netdev, John Bowler
In-Reply-To: <20060220030146.11f418dc@inspiron>
On Mon, Feb 20, 2006 at 03:01:46AM +0100, Alessandro Zummo wrote:
> On Mon, 20 Feb 2006 02:47:35 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > > Some Ethernet hardware implementations have no built-in storage for
> > > allocated MAC values - an example is the Intel IXP420 chip which has
> > > support for Ethernet but no defined way of storing allocated MAC values.
> > > With such hardware different board level implementations store the
> > > allocated MAC (or MACs) in different ways. Rather than put board level
> > > c
> > Silly question:
> >
> > Why can't this be implemented in user space using the SIOCSIFHWADDR
> > ioctl?
>
> Because sometimes you need to have networking available
> well before userspace.
>
> (netconsole, root over nfs, ...)
Why can't setting MAC addresses be done from initramfs?
> Best regards,
> Alessandro Zummo,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* (usagi-users 03613) Re: [PATCH] [NET]: NETFILTER: remove duplicated operation and fix order in skb_clone().
From: David S. Miller @ 2006-02-20 6:32 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, usagi-users, olivier.matz
In-Reply-To: <20060217.215101.09874309.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Fri, 17 Feb 2006 21:51:01 +0900 (JST)
> [NET]: NETFILTER: remove duplicated lines and fix order in skb_clone().
>
> Some of netfilter-related members are initalized / copied twice in
> skb_clone(). Remove one. Pointed out by Olivier MATZ <olivier.matz@6wind.com>.
>
> And this patch also fixes order of copying / clearing members.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Patch applied to net-2.6, thank you very much.
^ permalink raw reply
* [NETFILTER]: Fix skb->nf_bridge lifetime issues
From: Patrick McHardy @ 2006-02-20 7:44 UTC (permalink / raw)
To: Bart De Schuymer
Cc: Linux Netdev List, Netfilter Development Mailinglist,
David S. Miller
[-- Attachment #1: Type: text/plain, Size: 361 bytes --]
Bart, can you please have a look at this patch and ACK/NACK it?
We have a bugreport in the netfilter bugzilla of broken conntrack
with tunnels on top of bridge devices (#448), which should be cured
by this patch.
There is also another report of broken conntrack with vlan on top
of bridge devices (#400) that looks related, but probably this
patch won't help.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 3216 bytes --]
[NETFILTER]: Fix skb->nf_bridge lifetime issues
The bridge netfilter code simulates the NF_IP_PRE_ROUTING hook and skips
the real hook by registering with high priority and returning NF_STOP if
skb->nf_bridge is present and the BRNF_NF_BRIDGE_PREROUTING flag is not
set. The flag is only set during the simulated hook.
Because skb->nf_bridge is only freed when the packet is destroyed, the
packet will not only skip the first invocation of NF_IP_PRE_ROUTING, but
in the case of tunnel devices on top of the bridge also all further ones.
Forwarded packets from a bridge encapsulated by a tunnel device and sent
as locally outgoing packet will also still have the incorrect bridge
information from the input path attached.
We already have nf_reset calls on all RX/TX paths of tunnel devices,
so simply reset the nf_bridge field there too. As an added bonus,
the bridge information for locally delivered packets is now also freed
when the packet is queued to a socket.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 22e4dcb796d276db47a61c2382bdf2eaf76db32e
tree ccc5173acbe70506aa60e826e1881a4513f8c868
parent 337ba256a7e68f174a88ffba805b40622297fc22
author Patrick McHardy <kaber@trash.net> Mon, 20 Feb 2006 08:41:48 +0100
committer Patrick McHardy <kaber@trash.net> Mon, 20 Feb 2006 08:41:48 +0100
include/linux/skbuff.h | 24 ++++++++++++++----------
net/ipv4/netfilter/ipt_REJECT.c | 4 ----
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 838ce0f..65bf1fa 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1351,16 +1351,6 @@ static inline void nf_conntrack_put_reas
kfree_skb(skb);
}
#endif
-static inline void nf_reset(struct sk_buff *skb)
-{
- nf_conntrack_put(skb->nfct);
- skb->nfct = NULL;
-#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
- nf_conntrack_put_reasm(skb->nfct_reasm);
- skb->nfct_reasm = NULL;
-#endif
-}
-
#ifdef CONFIG_BRIDGE_NETFILTER
static inline void nf_bridge_put(struct nf_bridge_info *nf_bridge)
{
@@ -1373,6 +1363,20 @@ static inline void nf_bridge_get(struct
atomic_inc(&nf_bridge->use);
}
#endif /* CONFIG_BRIDGE_NETFILTER */
+static inline void nf_reset(struct sk_buff *skb)
+{
+ nf_conntrack_put(skb->nfct);
+ skb->nfct = NULL;
+#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
+ nf_conntrack_put_reasm(skb->nfct_reasm);
+ skb->nfct_reasm = NULL;
+#endif
+#ifdef CONFIG_BRIDGE_NETFILTER
+ nf_bridge_put(skb->nfct);
+ skb->nfct = NULL;
+#endif
+}
+
#else /* CONFIG_NETFILTER */
static inline void nf_reset(struct sk_buff *skb) {}
#endif /* CONFIG_NETFILTER */
diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c
index 26ea6c1..9d3b357 100644
--- a/net/ipv4/netfilter/ipt_REJECT.c
+++ b/net/ipv4/netfilter/ipt_REJECT.c
@@ -154,10 +154,6 @@ static void send_reset(struct sk_buff *o
/* This packet will not be the same as the other: clear nf fields */
nf_reset(nskb);
nskb->nfmark = 0;
-#ifdef CONFIG_BRIDGE_NETFILTER
- nf_bridge_put(nskb->nf_bridge);
- nskb->nf_bridge = NULL;
-#endif
tcph = (struct tcphdr *)((u_int32_t*)nskb->nh.iph + nskb->nh.iph->ihl);
^ permalink raw reply related
* Re: [NETFILTER]: Fix skb->nf_bridge lifetime issues
From: Patrick McHardy @ 2006-02-20 9:33 UTC (permalink / raw)
To: Bart De Schuymer
Cc: Linux Netdev List, Netfilter Development Mailinglist,
David S. Miller
In-Reply-To: <43F97342.9050806@trash.net>
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
Patrick McHardy wrote:
> Bart, can you please have a look at this patch and ACK/NACK it?
> We have a bugreport in the netfilter bugzilla of broken conntrack
> with tunnels on top of bridge devices (#448), which should be cured
> by this patch.
>
> +static inline void nf_reset(struct sk_buff *skb)
> +{
> + nf_conntrack_put(skb->nfct);
> + skb->nfct = NULL;
> +#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
> + nf_conntrack_put_reasm(skb->nfct_reasm);
> + skb->nfct_reasm = NULL;
> +#endif
> +#ifdef CONFIG_BRIDGE_NETFILTER
> + nf_bridge_put(skb->nfct);
> + skb->nfct = NULL;
> +#endif
> +}
This time compile tested and s/nfct/nf_bridge/ above.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 3226 bytes --]
[NETFILTER]: Fix skb->nf_bridge lifetime issues
The bridge netfilter code simulates the NF_IP_PRE_ROUTING hook and skips
the real hook by registering with high priority and returning NF_STOP if
skb->nf_bridge is present and the BRNF_NF_BRIDGE_PREROUTING flag is not
set. The flag is only set during the simulated hook.
Because skb->nf_bridge is only freed when the packet is destroyed, the
packet will not only skip the first invocation of NF_IP_PRE_ROUTING, but
in the case of tunnel devices on top of the bridge also all further ones.
Forwarded packets from a bridge encapsulated by a tunnel device and sent
as locally outgoing packet will also still have the incorrect bridge
information from the input path attached.
We already have nf_reset calls on all RX/TX paths of tunnel devices,
so simply reset the nf_bridge field there too. As an added bonus,
the bridge information for locally delivered packets is now also freed
when the packet is queued to a socket.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 5e5c34345f3ead2608e38d75f998dfeb7bb5df1c
tree 17bbdf2d4efc19888ec4fc0fd27c544677bd1949
parent 337ba256a7e68f174a88ffba805b40622297fc22
author Patrick McHardy <kaber@trash.net> Mon, 20 Feb 2006 10:33:14 +0100
committer Patrick McHardy <kaber@trash.net> Mon, 20 Feb 2006 10:33:14 +0100
include/linux/skbuff.h | 24 ++++++++++++++----------
net/ipv4/netfilter/ipt_REJECT.c | 4 ----
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 838ce0f..1a26110 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1351,16 +1351,6 @@ static inline void nf_conntrack_put_reas
kfree_skb(skb);
}
#endif
-static inline void nf_reset(struct sk_buff *skb)
-{
- nf_conntrack_put(skb->nfct);
- skb->nfct = NULL;
-#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
- nf_conntrack_put_reasm(skb->nfct_reasm);
- skb->nfct_reasm = NULL;
-#endif
-}
-
#ifdef CONFIG_BRIDGE_NETFILTER
static inline void nf_bridge_put(struct nf_bridge_info *nf_bridge)
{
@@ -1373,6 +1363,20 @@ static inline void nf_bridge_get(struct
atomic_inc(&nf_bridge->use);
}
#endif /* CONFIG_BRIDGE_NETFILTER */
+static inline void nf_reset(struct sk_buff *skb)
+{
+ nf_conntrack_put(skb->nfct);
+ skb->nfct = NULL;
+#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
+ nf_conntrack_put_reasm(skb->nfct_reasm);
+ skb->nfct_reasm = NULL;
+#endif
+#ifdef CONFIG_BRIDGE_NETFILTER
+ nf_bridge_put(skb->nf_bridge);
+ skb->nf_bridge = NULL;
+#endif
+}
+
#else /* CONFIG_NETFILTER */
static inline void nf_reset(struct sk_buff *skb) {}
#endif /* CONFIG_NETFILTER */
diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c
index 26ea6c1..9d3b357 100644
--- a/net/ipv4/netfilter/ipt_REJECT.c
+++ b/net/ipv4/netfilter/ipt_REJECT.c
@@ -154,10 +154,6 @@ static void send_reset(struct sk_buff *o
/* This packet will not be the same as the other: clear nf fields */
nf_reset(nskb);
nskb->nfmark = 0;
-#ifdef CONFIG_BRIDGE_NETFILTER
- nf_bridge_put(nskb->nf_bridge);
- nskb->nf_bridge = NULL;
-#endif
tcph = (struct tcphdr *)((u_int32_t*)nskb->nh.iph + nskb->nh.iph->ihl);
^ permalink raw reply related
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: David Vrabel @ 2006-02-20 12:16 UTC (permalink / raw)
To: Alessandro Zummo
Cc: Adrian Bunk, Martin Michlmayr, linux-kernel, netdev, John Bowler
In-Reply-To: <20060220030146.11f418dc@inspiron>
Alessandro Zummo wrote:
> On Mon, 20 Feb 2006 02:47:35 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
>
>
>>>Some Ethernet hardware implementations have no built-in storage for
>>>allocated MAC values - an example is the Intel IXP420 chip which has
>>>support for Ethernet but no defined way of storing allocated MAC values.
>>>With such hardware different board level implementations store the
>>>allocated MAC (or MACs) in different ways. Rather than put board level
>>>code
For those not familar with the IXP4xx, the Ethernet drivers are
proprietary and given that there are no other proposed users of this
maclist code there's no need for it in the kernel at this time.
>>Silly question:
>>
>>Why can't this be implemented in user space using the SIOCSIFHWADDR
>>ioctl?
I'm with Adrian on this -- it's a job for userspace. The storage of the
MAC address isn't something that's necessarily board specific anyway but
could depend on which bootloader is used and/or the bootloader version.
> Because sometimes you need to have networking available
> well before userspace.
In the specific case of the IXP4xx, you presumably have some userspace
available because you've just loaded the NPE firmware from it, yes?
David Vrabel
^ permalink raw reply
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: Alessandro Zummo @ 2006-02-20 12:57 UTC (permalink / raw)
To: David Vrabel
Cc: Adrian Bunk, Martin Michlmayr, linux-kernel, netdev, John Bowler
In-Reply-To: <43F9B32B.3090203@cantab.net>
On Mon, 20 Feb 2006 12:16:43 +0000
David Vrabel <dvrabel@cantab.net> wrote:
> >>>Some Ethernet hardware implementations have no built-in storage for
> >>>allocated MAC values - an example is the Intel IXP420 chip which has
> >>>support for Ethernet but no defined way of storing allocated MAC values.
> >>>With such hardware different board level implementations store the
> >>>allocated MAC (or MACs) in different ways. Rather than put board level
> >>>code
> For those not familar with the IXP4xx, the Ethernet drivers are
> proprietary and given that there are no other proposed users of this
> maclist code there's no need for it in the kernel at this time.
> >>Why can't this be implemented in user space using the SIOCSIFHWADDR
> >>ioctl?
> I'm with Adrian on this -- it's a job for userspace. The storage of the
> MAC address isn't something that's necessarily board specific anyway but
> could depend on which bootloader is used and/or the bootloader version.
> > Because sometimes you need to have networking available
> > well before userspace.
>
> In the specific case of the IXP4xx, you presumably have some userspace
> available because you've just loaded the NPE firmware from it, yes?
Hi David,
you're certainly right on the ixp4xx, but the are other uses
for this driver which we are working on.. for example,
some Cirrus Logic ARM based chips (ep93xx) have an ethernet device
that could benefit from that.
I'm pretty sure that there are and will be more devices
with such requirements, with either proprietary or
open source drivers. My opinion is that a maclist alike
facility can clean some of the mess in that area.
If we implement such a thing in userspace every distribution
will need to be aware of a specific trick for a specific
board. If we have a clean facility in the kernel, userspace
will not need to care.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
http://www.towertech.it
^ permalink raw reply
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: Russell King @ 2006-02-20 13:02 UTC (permalink / raw)
To: Alessandro Zummo
Cc: David Vrabel, Adrian Bunk, Martin Michlmayr, linux-kernel, netdev,
John Bowler
In-Reply-To: <20060220135718.038b675b@inspiron>
On Mon, Feb 20, 2006 at 01:57:18PM +0100, Alessandro Zummo wrote:
> you're certainly right on the ixp4xx, but the are other uses
> for this driver which we are working on.. for example,
> some Cirrus Logic ARM based chips (ep93xx) have an ethernet device
> that could benefit from that.
An alternative solution (suggested in the past) would be to have a
generic kernel command line option such as: mac=<netdev>,<macaddr>
It nicely solves the "no mac address" issue in a lot (if not all)
of the cases.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: Lennert Buytenhek @ 2006-02-20 13:07 UTC (permalink / raw)
To: Alessandro Zummo
Cc: David Vrabel, Adrian Bunk, Martin Michlmayr, linux-kernel, netdev,
John Bowler
In-Reply-To: <20060220135718.038b675b@inspiron>
On Mon, Feb 20, 2006 at 01:57:18PM +0100, Alessandro Zummo wrote:
> you're certainly right on the ixp4xx, but the are other uses
> for this driver which we are working on.. for example,
> some Cirrus Logic ARM based chips (ep93xx) have an ethernet device
> that could benefit from that.
Many platforms have the same problem (esp. embedded ones), but that
doesn't mean that maclist is necessarily the best solution.
The main problem I see with maclist (correct me if I'm wrong) is that
there can be multiple devices in the system that need to get their
MAC address from somewhere, and maclist doesn't make the distinction
which address belongs to what. The main issue I have with it is that
it's too general, and that it's lots of code.
I don't think something as complex as maclist is necessary to solve
the problem. For example, why don't you just have an unsigned char
ixp4xx_mac_addr[6] in the ixp4xx core code, have the ixp4xx board code
fill that in, and have the ixp4xx ethernet driver use that?
Or just pass the MAC along in platform device style. What I did in
drivers/net/ixp2000/ was to have enp2611.c (board-specific code) read
the MAC from the board, and pass it to ixpdev.c (generic code) in the
net_device structure.
cheers,
Lennert
^ permalink raw reply
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: jamal @ 2006-02-20 13:15 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: Alessandro Zummo, David Vrabel, Adrian Bunk, Martin Michlmayr,
linux-kernel, netdev, John Bowler
In-Reply-To: <20060220130712.GA24784@xi.wantstofly.org>
On Mon, 2006-20-02 at 14:07 +0100, Lennert Buytenhek wrote:
> On Mon, Feb 20, 2006 at 01:57:18PM +0100, Alessandro Zummo wrote:
>
> Or just pass the MAC along in platform device style. What I did in
> drivers/net/ixp2000/ was to have enp2611.c (board-specific code) read
> the MAC from the board, and pass it to ixpdev.c (generic code) in the
> net_device structure.
>
yep, this is what i have seen done in a lot of embedded boards
containing switching chips (If i am not mistaken there is a 4 port
switch in the IXP4xx)
cheers,
jamal
^ permalink raw reply
* Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: Alessandro Zummo @ 2006-02-20 13:22 UTC (permalink / raw)
To: Russell King
Cc: David Vrabel, Adrian Bunk, Martin Michlmayr, linux-kernel, netdev,
John Bowler
In-Reply-To: <20060220130203.GA22147@flint.arm.linux.org.uk>
On Mon, 20 Feb 2006 13:02:03 +0000
Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > for this driver which we are working on.. for example,
> > some Cirrus Logic ARM based chips (ep93xx) have an ethernet device
> > that could benefit from that.
>
> An alternative solution (suggested in the past) would be to have a
> generic kernel command line option such as: mac=<netdev>,<macaddr>
>
> It nicely solves the "no mac address" issue in a lot (if not all)
> of the cases.
That would help, but it can't easily be implemented when you are
targeting consumer devices like nas, routers et al which already
have been widely deployed.
I know that the solution would be to fix the bootloader, but
Joe Average is a little bit scared of reflashing it.
A maclist-alike system could help to solve that situation.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
http://www.towertech.it
^ 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