* [PATCH 02/05] ipv6: RFC4214 Support (2)
From: osprey67 @ 2007-11-08 20:41 UTC (permalink / raw)
To: netdev
From: Fred L. Templin <osprey67@yahoo.com>
This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
"ip" utility with device names beginning with: "isatap".
The following diffs are specific to the Linux 2.6.24-rc2
kernel distribution.
Signed-off-by: Fred L. Templin <osprey67@yahoo.com>
---
--- linux-2.6.24-rc2/include/net/addrconf.h.orig 2007-11-08 12:06:17.000000000 -0800
+++ linux-2.6.24-rc2/include/net/addrconf.h 2007-11-08 08:27:24.000000000 -0800
@@ -241,6 +241,37 @@ static inline int ipv6_addr_is_ll_all_ro
addr->s6_addr32[3] == htonl(0x00000002));
}
+#if defined(CONFIG_IPV6_ISATAP)
+static inline int ipv6_isatap_eui64(u8 *eui, __be32 addr)
+{
+
+ /* RFC3330 Special-Use IPv4 Addresses */
+ eui[0] = (((addr & htonl(0xFF000000)) == htonl(0x00000000)) ||
+ ((addr & htonl(0xFF000000)) == htonl(0x0A000000)) ||
+ ((addr & htonl(0xFF000000)) == htonl(0x0D000000)) ||
+ ((addr & htonl(0xFF000000)) == htonl(0x18000000)) ||
+ ((addr & htonl(0xFF000000)) == htonl(0x7F000000)) ||
+ ((addr & htonl(0xFFFF0000)) == htonl(0xA9FE0000)) ||
+ ((addr & htonl(0xFFF00000)) == htonl(0xAC100000)) ||
+ ((addr & htonl(0xFFFFFF00)) == htonl(0xC0000200)) ||
+ ((addr & htonl(0xFFFFFF00)) == htonl(0xC0586300)) ||
+ ((addr & htonl(0xFFFF0000)) == htonl(0xC0A80000)) ||
+ ((addr & htonl(0xFFFE0000)) == htonl(0xC6120000)) ||
+ ((addr & htonl(0xF0000000)) == htonl(0xE0000000)) ||
+ ((addr & htonl(0xF0000000)) == htonl(0xF0000000))) ?
+ 0x00 : 0x02;
+
+ eui[1] = 0; eui[2] = 0x5E; eui[3] = 0xFE;
+ memcpy (eui+4, &addr, 4);
+ return 0;
+}
+
+static inline int ipv6_addr_is_isatap(const struct in6_addr *addr)
+{
+ return ((addr->s6_addr32[2] | htonl(0x02000000)) == htonl(0x02005EFE));
+}
+#endif
+
#ifdef CONFIG_PROC_FS
extern int if6_proc_init(void);
extern void if6_proc_exit(void);
^ permalink raw reply
* [PATCH 01/05] ipv6: RFC4214 Support (2)
From: osprey67 @ 2007-11-08 20:29 UTC (permalink / raw)
To: netdev
From: Fred L. Templin <osprey67@yahoo.com>
This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
"ip" utility with device names beginning with: "isatap".
The following diffs are specific to the Linux 2.6.24-rc2
kernel distribution.
Signed-off-by: Fred L. Templin <osprey67@yahoo.com>
---
--- linux-2.6.24-rc2/include/linux/if.h.orig 2007-11-08 12:05:47.000000000 -0800
+++ linux-2.6.24-rc2/include/linux/if.h 2007-11-08 08:26:44.000000000 -0800
@@ -61,6 +61,7 @@
#define IFF_MASTER_ALB 0x10 /* bonding master, balance-alb. */
#define IFF_BONDING 0x20 /* bonding master or slave */
#define IFF_SLAVE_NEEDARP 0x40 /* need ARPs for validation */
+#define IFF_ISATAP 0x80 /* ISATAP interface (RFC4214) */
#define IF_GET_IFACE 0x0001 /* for querying only */
#define IF_GET_PROTO 0x0002
^ permalink raw reply
* Re: [PATCH] ipconfig.c : implement DHCP Class-identifier
From: Ilpo Järvinen @ 2007-11-08 20:27 UTC (permalink / raw)
To: Rainer Jochem
Cc: davem, kuznet, jmorris, kaber, linux-kernel, netdev, pcernko
In-Reply-To: <20071108143205.GA22490@mpi-sb.mpg.de>
On Thu, 8 Nov 2007, Rainer Jochem wrote:
> @@ -620,6 +622,17 @@ ic_dhcp_init_options(u8 *options)
> *e++ = sizeof(ic_req_params);
> memcpy(e, ic_req_params, sizeof(ic_req_params));
> e += sizeof(ic_req_params);
> +
> + // Send it only if the according kernel parameter was set
No C99 comments please. Though I'm not sure if this comment is that
necessary anyway...
> + if (*vendor_class_identifier) {
> + printk(KERN_INFO "Sending class identifier \"%s\"\n",
> + vendor_class_identifier);
> + *e++ = 60; /* Class-identifier */
> + *e++ = strlen(vendor_class_identifier);
> + memcpy(e, vendor_class_identifier,
> + strlen(vendor_class_identifier));
> + e += strlen(vendor_class_identifier);
> + }
> }
>
> *e++ = 255; /* End of the list */
--
i.
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Scott Wood @ 2007-11-08 20:20 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <1194442844.3571.14.camel@p60635-ste.ids.de>
Sergej Stepanov wrote:
> If both mdio and mdc controlling pins are on the same processor port,
> one resource should be used.
> Otherwise, two resources are used: the 1-st - mdio, the 2-nd - mdc.
How about:
The first reg resource is the I/O port register block on which MDIO
resides. The second reg resource is the I/O port register block on
which MDC resides. If there is only one reg resource, it is used for
both MDIO and MDC.
We also need to change the reference to port C in fsl,mdio-pin and
fsl,mdc-pin.
-Scott
^ permalink raw reply
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Kim Phillips @ 2007-11-08 19:11 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, linuxppc-dev, paulus, Li Yang, jgarzik
In-Reply-To: <20071108183952.GA18117@localhost.localdomain>
On Thu, 8 Nov 2007 21:39:52 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> On Thu, Nov 08, 2007 at 12:15:08PM -0600, Kim Phillips wrote:
> > On Thu, 8 Nov 2007 17:16:11 +0300
> > Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> >
> > > On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> > > > Hello all,
> > > >
> > > > the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> > > > according to erratum #2 (erratum text included below). Basically the
> > > > most intrusive part is the addition of two new RGMII Internal Delay
> > > > modes; one for TX delay only, and the other for RX delay only (i.e, not
> > > > both at the same time).
> > > >
> > > > Please review, and since this affects both netdev and powerpc trees,
> > > > one maintainer should ack them for the other to push upstream (i.e,
> > > > Kumar acks them, and Leo picks them up to go through netdev or the
> > > > other way around; either way is fine with me). I'm hoping they're
> > > > trivial enough to go in 2.6.24.
> > > >
> > > > Depending on how the review goes, a follow-on patch to u-boot will be
> > > > sent out that fixes up the phy-connection-type in the device tree (from
> > > > "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).
> > >
> > > I've upgraded CPU to rev2.1, board rev0.3.
> > >
> > thanks for testing this. I tested these patches on a "pilot assy 0.3".
>
> Same here.
>
> > > Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
> > > the results:
> > >
> > > If I use -rxid, then geth not able to transmit anything.
> > > With -txid geth not able to receive anything.
> > >
> > > With just -id everything works fine though...
> > >
> > >
> > > Maybe there should be another condition, in addition to cpu rev2.1?
> > >
> > the errata simply states 'pilot boards', but we can probably modify
> > u-boot to look at the cpu rev and the board rev (BCSR 12).
> >
> > My bcsr12 looks like:
> >
> > => md.b f800000c 1
> > f800000c: 10 .
> >
> > what is yours?
>
> => md.b f800000c 1
> f800000c: 10 .
>
> :-/
>
> U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
> CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
>
> root@b1:~# cat /proc/cpuinfo
> processor : 0
> cpu : e300c1
> clock : 528.000000MHz
> revision : 3.1 (pvr 8083 0031)
> bogomips : 131.58
> timebase : 66000000
> platform : MPC836x MDS
>
check. :/
>
> + /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
> + svid = mfspr(SPRN_SVR);
> + if (svid == 0x80480021) {
>
> ^^ that branch executes on the board I'm testing.
right, but whether it does or not doesn't affect your failure outcome
either I'm assuming.
> > If it's something like 0x03, the u-boot patch will probably look like:
> >
> > if ((bcsr[12] == 0x10) &&
> > (immr->sysconf.spridr == SPR_8360_REV21 ||
> > immr->sysconf.spridr == SPR_8360E_REV21))
> > /* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> > ...
> >
> > but these linux patches would remain the same (the clk and data delay
> > settings for the UCC's are still valid; it's just the PHY config
> > that is triggering your problem from what I can tell).
>
> Yup, most likely this is not UCC specific, but PHY. For some reason
> delays making harm here...
hmm..
Net: UEC: PHY is Marvell 88E11x1 (1410cc2)
I have jumper JP1 set to 3.3V.
can you send me your:
=> md.b f8000000 15
f8000000: 04 04 00 c6 94 60 00 00 ac 2f 00 b8 10 3f 30 02 .....`.../...?0.
f8000010: 05 07 05 15 11 .....
and maybe try the following on top of these 5 patches (to specify rgmii
mode in the bcsr's):
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 0a72260..753071e 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -98,6 +98,11 @@ static void __init mpc836x_mds_setup_arch(void)
!= NULL){
uint svid;
+ /* configure RGMII mode for both GETH ports */
+#define BCSR8_TSECXM_RGMII 0xf0
+ clrbits8(&bcsr_regs[8], BCSR8_TSECXM_RGMII);
+
+
/* Reset the Ethernet PHY */
#define BCSR9_GETHRST 0x20
clrbits8(&bcsr_regs[9], BCSR9_GETHRST);
Thanks,
Kim
^ permalink raw reply related
* Re: [2.6 patch] drivers/net/netxen/: cleanups
From: Dhananjay Phadke @ 2007-11-08 18:55 UTC (permalink / raw)
To: Adrian Bunk; +Cc: jgarzik, netdev, linux-kernel
In-Reply-To: <20071105170731.GP12045@stusta.de>
This looks good to me, I might chop off these #if 0 'ed functions in
my next round of patches.
Acked-by: Dhananjay Phadke <dhananjay@netxen.com>
On 11/5/07, Adrian Bunk <bunk@kernel.org> wrote:
> This patch contains the following cleanups:
> - static functions in .c files shouldn't be marked inline
> - make needlessly global code static
> - #if 0 unused code
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
> ---
>
> drivers/net/netxen/netxen_nic.h | 14 ----
> drivers/net/netxen/netxen_nic_hw.c | 19 +++---
> drivers/net/netxen/netxen_nic_hw.h | 8 --
> drivers/net/netxen/netxen_nic_init.c | 70 ++++++++++++-----------
> drivers/net/netxen/netxen_nic_isr.c | 7 +-
> drivers/net/netxen/netxen_nic_main.c | 9 +-
> drivers/net/netxen/netxen_nic_niu.c | 26 +++++---
> drivers/net/netxen/netxen_nic_phan_reg.h | 7 --
> 8 files changed, 76 insertions(+), 84 deletions(-)
>
> dbc7aeed37e41cd37a01cce259e5c0ab01f8dd88
> diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
> index fbc2553..ef9f986 100644
> --- a/drivers/net/netxen/netxen_nic.h
> +++ b/drivers/net/netxen/netxen_nic.h
> @@ -1015,14 +1015,8 @@ int netxen_niu_xgbe_enable_phy_interrupts(struct netxen_adapter *adapter);
> int netxen_niu_gbe_enable_phy_interrupts(struct netxen_adapter *adapter);
> int netxen_niu_xgbe_disable_phy_interrupts(struct netxen_adapter *adapter);
> int netxen_niu_gbe_disable_phy_interrupts(struct netxen_adapter *adapter);
> -int netxen_niu_xgbe_clear_phy_interrupts(struct netxen_adapter *adapter);
> -int netxen_niu_gbe_clear_phy_interrupts(struct netxen_adapter *adapter);
> void netxen_nic_xgbe_handle_phy_intr(struct netxen_adapter *adapter);
> void netxen_nic_gbe_handle_phy_intr(struct netxen_adapter *adapter);
> -void netxen_niu_gbe_set_mii_mode(struct netxen_adapter *adapter, int port,
> - long enable);
> -void netxen_niu_gbe_set_gmii_mode(struct netxen_adapter *adapter, int port,
> - long enable);
> int netxen_niu_gbe_phy_read(struct netxen_adapter *adapter, long reg,
> __u32 * readval);
> int netxen_niu_gbe_phy_write(struct netxen_adapter *adapter,
> @@ -1045,7 +1039,6 @@ int netxen_nic_hw_write_wx(struct netxen_adapter *adapter, u64 off, void *data,
> int len);
> void netxen_crb_writelit_adapter(struct netxen_adapter *adapter,
> unsigned long off, int data);
> -int netxen_nic_erase_pxe(struct netxen_adapter *adapter);
>
> /* Functions from netxen_nic_init.c */
> void netxen_free_adapter_offload(struct netxen_adapter *adapter);
> @@ -1064,15 +1057,10 @@ int netxen_flash_erase_secondary(struct netxen_adapter *adapter);
> int netxen_flash_erase_primary(struct netxen_adapter *adapter);
> void netxen_halt_pegs(struct netxen_adapter *adapter);
>
> -int netxen_rom_fast_write(struct netxen_adapter *adapter, int addr, int data);
> int netxen_rom_se(struct netxen_adapter *adapter, int addr);
> -int netxen_do_rom_se(struct netxen_adapter *adapter, int addr);
>
> /* Functions from netxen_nic_isr.c */
> int netxen_nic_link_ok(struct netxen_adapter *adapter);
> -void netxen_nic_isr_other(struct netxen_adapter *adapter);
> -void netxen_indicate_link_status(struct netxen_adapter *adapter, u32 link);
> -void netxen_handle_port_int(struct netxen_adapter *adapter, u32 enable);
> void netxen_initialize_adapter_sw(struct netxen_adapter *adapter);
> void netxen_initialize_adapter_hw(struct netxen_adapter *adapter);
> void *netxen_alloc(struct pci_dev *pdev, size_t sz, dma_addr_t * ptr,
> @@ -1089,8 +1077,6 @@ int netxen_nic_tx_has_work(struct netxen_adapter *adapter);
> void netxen_watchdog_task(struct work_struct *work);
> void netxen_post_rx_buffers(struct netxen_adapter *adapter, u32 ctx,
> u32 ringid);
> -void netxen_post_rx_buffers_nodb(struct netxen_adapter *adapter, u32 ctx,
> - u32 ringid);
> int netxen_process_cmd_ring(unsigned long data);
> u32 netxen_process_rcv_ring(struct netxen_adapter *adapter, int ctx, int max);
> void netxen_nic_set_multi(struct net_device *netdev);
> diff --git a/drivers/net/netxen/netxen_nic_hw.c b/drivers/net/netxen/netxen_nic_hw.c
> index 2c19b8d..b2c7861 100644
> --- a/drivers/net/netxen/netxen_nic_hw.c
> +++ b/drivers/net/netxen/netxen_nic_hw.c
> @@ -33,7 +33,6 @@
>
> #include "netxen_nic.h"
> #include "netxen_nic_hw.h"
> -#define DEFINE_GLOBAL_RECV_CRB
> #include "netxen_nic_phan_reg.h"
>
>
> @@ -244,12 +243,15 @@ struct netxen_recv_crb recv_crb_registers[] = {
> },
> };
>
> -u64 ctx_addr_sig_regs[][3] = {
> +static u64 ctx_addr_sig_regs[][3] = {
> {NETXEN_NIC_REG(0x188), NETXEN_NIC_REG(0x18c), NETXEN_NIC_REG(0x1c0)},
> {NETXEN_NIC_REG(0x190), NETXEN_NIC_REG(0x194), NETXEN_NIC_REG(0x1c4)},
> {NETXEN_NIC_REG(0x198), NETXEN_NIC_REG(0x19c), NETXEN_NIC_REG(0x1c8)},
> {NETXEN_NIC_REG(0x1a0), NETXEN_NIC_REG(0x1a4), NETXEN_NIC_REG(0x1cc)}
> };
> +#define CRB_CTX_ADDR_REG_LO(FUNC_ID) (ctx_addr_sig_regs[FUNC_ID][0])
> +#define CRB_CTX_ADDR_REG_HI(FUNC_ID) (ctx_addr_sig_regs[FUNC_ID][2])
> +#define CRB_CTX_SIGNATURE_REG(FUNC_ID) (ctx_addr_sig_regs[FUNC_ID][1])
>
>
> /* PCI Windowing for DDR regions. */
> @@ -279,8 +281,8 @@ u64 ctx_addr_sig_regs[][3] = {
>
> #define NETXEN_NIC_WINDOW_MARGIN 0x100000
>
> -unsigned long netxen_nic_pci_set_window(struct netxen_adapter *adapter,
> - unsigned long long addr);
> +static unsigned long netxen_nic_pci_set_window(struct netxen_adapter *adapter,
> + unsigned long long addr);
> void netxen_free_hw_resources(struct netxen_adapter *adapter);
>
> int netxen_nic_set_mac(struct net_device *netdev, void *p)
> @@ -886,11 +888,10 @@ void netxen_nic_read_w0(struct netxen_adapter *adapter, u32 index, u32 * value)
> netxen_nic_pci_change_crbwindow(adapter, 1);
> }
>
> -int netxen_pci_set_window_warning_count = 0;
> +static int netxen_pci_set_window_warning_count = 0;
>
> -unsigned long
> -netxen_nic_pci_set_window(struct netxen_adapter *adapter,
> - unsigned long long addr)
> +static unsigned long netxen_nic_pci_set_window(struct netxen_adapter *adapter,
> + unsigned long long addr)
> {
> static int ddr_mn_window = -1;
> static int qdr_sn_window = -1;
> @@ -952,6 +953,7 @@ netxen_nic_pci_set_window(struct netxen_adapter *adapter,
> return addr;
> }
>
> +#if 0
> int
> netxen_nic_erase_pxe(struct netxen_adapter *adapter)
> {
> @@ -962,6 +964,7 @@ netxen_nic_erase_pxe(struct netxen_adapter *adapter)
> }
> return 0;
> }
> +#endif /* 0 */
>
> int netxen_nic_get_board_info(struct netxen_adapter *adapter)
> {
> diff --git a/drivers/net/netxen/netxen_nic_hw.h b/drivers/net/netxen/netxen_nic_hw.h
> index 245bf13..197e1fc 100644
> --- a/drivers/net/netxen/netxen_nic_hw.h
> +++ b/drivers/net/netxen/netxen_nic_hw.h
> @@ -520,15 +520,11 @@ int netxen_niu_set_promiscuous_mode(struct netxen_adapter *adapter,
> int netxen_niu_xg_set_promiscuous_mode(struct netxen_adapter *adapter,
> netxen_niu_prom_mode_t mode);
>
> -/* get/set the MAC address for a given MAC */
> -int netxen_niu_macaddr_get(struct netxen_adapter *adapter,
> - netxen_ethernet_macaddr_t * addr);
> +/* set the MAC address for a given MAC */
> int netxen_niu_macaddr_set(struct netxen_adapter *adapter,
> netxen_ethernet_macaddr_t addr);
>
> -/* XG versons */
> -int netxen_niu_xg_macaddr_get(struct netxen_adapter *adapter,
> - netxen_ethernet_macaddr_t * addr);
> +/* XG version */
> int netxen_niu_xg_macaddr_set(struct netxen_adapter *adapter,
> netxen_ethernet_macaddr_t addr);
>
> diff --git a/drivers/net/netxen/netxen_nic_init.c b/drivers/net/netxen/netxen_nic_init.c
> index 3758926..8667e8f 100644
> --- a/drivers/net/netxen/netxen_nic_init.c
> +++ b/drivers/net/netxen/netxen_nic_init.c
> @@ -54,13 +54,17 @@ static unsigned int crb_addr_xform[NETXEN_MAX_CRB_XFORM];
>
> #define NETXEN_NIC_XDMA_RESET 0x8000ff
>
> -static inline void
> -netxen_nic_locked_write_reg(struct netxen_adapter *adapter,
> - unsigned long off, int *data)
> +static void netxen_post_rx_buffers_nodb(struct netxen_adapter *adapter,
> + uint32_t ctx, uint32_t ringid);
> +
> +#if 0
> +static void netxen_nic_locked_write_reg(struct netxen_adapter *adapter,
> + unsigned long off, int *data)
> {
> void __iomem *addr = pci_base_offset(adapter, off);
> writel(*data, addr);
> }
> +#endif /* 0 */
>
> static void crb_addr_transform_setup(void)
> {
> @@ -255,7 +259,7 @@ void netxen_initialize_adapter_ops(struct netxen_adapter *adapter)
> * netxen_decode_crb_addr(0 - utility to translate from internal Phantom CRB
> * address to external PCI CRB address.
> */
> -u32 netxen_decode_crb_addr(u32 addr)
> +static u32 netxen_decode_crb_addr(u32 addr)
> {
> int i;
> u32 base_addr, offset, pci_base;
> @@ -282,7 +286,7 @@ static long rom_max_timeout = 100;
> static long rom_lock_timeout = 10000;
> static long rom_write_timeout = 700;
>
> -static inline int rom_lock(struct netxen_adapter *adapter)
> +static int rom_lock(struct netxen_adapter *adapter)
> {
> int iter;
> u32 done = 0;
> @@ -312,7 +316,7 @@ static inline int rom_lock(struct netxen_adapter *adapter)
> return 0;
> }
>
> -int netxen_wait_rom_done(struct netxen_adapter *adapter)
> +static int netxen_wait_rom_done(struct netxen_adapter *adapter)
> {
> long timeout = 0;
> long done = 0;
> @@ -329,7 +333,7 @@ int netxen_wait_rom_done(struct netxen_adapter *adapter)
> return 0;
> }
>
> -static inline int netxen_rom_wren(struct netxen_adapter *adapter)
> +static int netxen_rom_wren(struct netxen_adapter *adapter)
> {
> /* Set write enable latch in ROM status register */
> netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_ABYTE_CNT, 0);
> @@ -341,15 +345,15 @@ static inline int netxen_rom_wren(struct netxen_adapter *adapter)
> return 0;
> }
>
> -static inline unsigned int netxen_rdcrbreg(struct netxen_adapter *adapter,
> - unsigned int addr)
> +static unsigned int netxen_rdcrbreg(struct netxen_adapter *adapter,
> + unsigned int addr)
> {
> unsigned int data = 0xdeaddead;
> data = netxen_nic_reg_read(adapter, addr);
> return data;
> }
>
> -static inline int netxen_do_rom_rdsr(struct netxen_adapter *adapter)
> +static int netxen_do_rom_rdsr(struct netxen_adapter *adapter)
> {
> netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_INSTR_OPCODE,
> M25P_INSTR_RDSR);
> @@ -359,7 +363,7 @@ static inline int netxen_do_rom_rdsr(struct netxen_adapter *adapter)
> return netxen_rdcrbreg(adapter, NETXEN_ROMUSB_ROM_RDATA);
> }
>
> -static inline void netxen_rom_unlock(struct netxen_adapter *adapter)
> +static void netxen_rom_unlock(struct netxen_adapter *adapter)
> {
> u32 val;
>
> @@ -368,7 +372,7 @@ static inline void netxen_rom_unlock(struct netxen_adapter *adapter)
>
> }
>
> -int netxen_rom_wip_poll(struct netxen_adapter *adapter)
> +static int netxen_rom_wip_poll(struct netxen_adapter *adapter)
> {
> long timeout = 0;
> long wip = 1;
> @@ -385,8 +389,8 @@ int netxen_rom_wip_poll(struct netxen_adapter *adapter)
> return 0;
> }
>
> -static inline int do_rom_fast_write(struct netxen_adapter *adapter, int addr,
> - int data)
> +static int do_rom_fast_write(struct netxen_adapter *adapter, int addr,
> + int data)
> {
> if (netxen_rom_wren(adapter)) {
> return -1;
> @@ -404,8 +408,8 @@ static inline int do_rom_fast_write(struct netxen_adapter *adapter, int addr,
> return netxen_rom_wip_poll(adapter);
> }
>
> -static inline int
> -do_rom_fast_read(struct netxen_adapter *adapter, int addr, int *valp)
> +static int do_rom_fast_read(struct netxen_adapter *adapter,
> + int addr, int *valp)
> {
> cond_resched();
>
> @@ -427,9 +431,8 @@ do_rom_fast_read(struct netxen_adapter *adapter, int addr, int *valp)
> return 0;
> }
>
> -static inline int
> -do_rom_fast_read_words(struct netxen_adapter *adapter, int addr,
> - u8 *bytes, size_t size)
> +static int do_rom_fast_read_words(struct netxen_adapter *adapter, int addr,
> + u8 *bytes, size_t size)
> {
> int addridx;
> int ret = 0;
> @@ -473,6 +476,7 @@ int netxen_rom_fast_read(struct netxen_adapter *adapter, int addr, int *valp)
> return ret;
> }
>
> +#if 0
> int netxen_rom_fast_write(struct netxen_adapter *adapter, int addr, int data)
> {
> int ret = 0;
> @@ -484,9 +488,10 @@ int netxen_rom_fast_write(struct netxen_adapter *adapter, int addr, int data)
> netxen_rom_unlock(adapter);
> return ret;
> }
> +#endif /* 0 */
>
> -static inline int do_rom_fast_write_words(struct netxen_adapter *adapter,
> - int addr, u8 *bytes, size_t size)
> +static int do_rom_fast_write_words(struct netxen_adapter *adapter,
> + int addr, u8 *bytes, size_t size)
> {
> int addridx = addr;
> int ret = 0;
> @@ -548,7 +553,7 @@ int netxen_rom_fast_write_words(struct netxen_adapter *adapter, int addr,
> return ret;
> }
>
> -int netxen_rom_wrsr(struct netxen_adapter *adapter, int data)
> +static int netxen_rom_wrsr(struct netxen_adapter *adapter, int data)
> {
> int ret;
>
> @@ -567,7 +572,7 @@ int netxen_rom_wrsr(struct netxen_adapter *adapter, int data)
> return netxen_rom_wip_poll(adapter);
> }
>
> -int netxen_rom_rdsr(struct netxen_adapter *adapter)
> +static int netxen_rom_rdsr(struct netxen_adapter *adapter)
> {
> int ret;
>
> @@ -632,7 +637,7 @@ out_kfree:
> return ret;
> }
>
> -int netxen_do_rom_se(struct netxen_adapter *adapter, int addr)
> +static int netxen_do_rom_se(struct netxen_adapter *adapter, int addr)
> {
> netxen_rom_wren(adapter);
> netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_ADDRESS, addr);
> @@ -646,7 +651,7 @@ int netxen_do_rom_se(struct netxen_adapter *adapter, int addr)
> return netxen_rom_wip_poll(adapter);
> }
>
> -void check_erased_flash(struct netxen_adapter *adapter, int addr)
> +static void check_erased_flash(struct netxen_adapter *adapter, int addr)
> {
> int i;
> int val;
> @@ -682,8 +687,8 @@ int netxen_rom_se(struct netxen_adapter *adapter, int addr)
> return ret;
> }
>
> -int
> -netxen_flash_erase_sections(struct netxen_adapter *adapter, int start, int end)
> +static int netxen_flash_erase_sections(struct netxen_adapter *adapter,
> + int start, int end)
> {
> int ret = FLASH_SUCCESS;
> int i;
> @@ -990,7 +995,7 @@ int netxen_nic_rx_has_work(struct netxen_adapter *adapter)
> return 0;
> }
>
> -static inline int netxen_nic_check_temp(struct netxen_adapter *adapter)
> +static int netxen_nic_check_temp(struct netxen_adapter *adapter)
> {
> struct net_device *netdev = adapter->netdev;
> uint32_t temp, temp_state, temp_val;
> @@ -1064,9 +1069,8 @@ void netxen_watchdog_task(struct work_struct *work)
> * and if the number of receives exceeds RX_BUFFERS_REFILL, then we
> * invoke the routine to send more rx buffers to the Phantom...
> */
> -void
> -netxen_process_rcv(struct netxen_adapter *adapter, int ctxid,
> - struct status_desc *desc)
> +static void netxen_process_rcv(struct netxen_adapter *adapter, int ctxid,
> + struct status_desc *desc)
> {
> struct pci_dev *pdev = adapter->pdev;
> struct net_device *netdev = adapter->netdev;
> @@ -1460,8 +1464,8 @@ void netxen_post_rx_buffers(struct netxen_adapter *adapter, u32 ctx, u32 ringid)
> }
> }
>
> -void netxen_post_rx_buffers_nodb(struct netxen_adapter *adapter, uint32_t ctx,
> - uint32_t ringid)
> +static void netxen_post_rx_buffers_nodb(struct netxen_adapter *adapter,
> + uint32_t ctx, uint32_t ringid)
> {
> struct pci_dev *pdev = adapter->ahw.pdev;
> struct sk_buff *skb;
> diff --git a/drivers/net/netxen/netxen_nic_isr.c b/drivers/net/netxen/netxen_nic_isr.c
> index b2de6b6..0a261de 100644
> --- a/drivers/net/netxen/netxen_nic_isr.c
> +++ b/drivers/net/netxen/netxen_nic_isr.c
> @@ -66,7 +66,8 @@ struct net_device_stats *netxen_nic_get_stats(struct net_device *netdev)
> return stats;
> }
>
> -void netxen_indicate_link_status(struct netxen_adapter *adapter, u32 link)
> +static void netxen_indicate_link_status(struct netxen_adapter *adapter,
> + u32 link)
> {
> struct net_device *netdev = adapter->netdev;
>
> @@ -76,6 +77,7 @@ void netxen_indicate_link_status(struct netxen_adapter *adapter, u32 link)
> netif_carrier_off(netdev);
> }
>
> +#if 0
> void netxen_handle_port_int(struct netxen_adapter *adapter, u32 enable)
> {
> __u32 int_src;
> @@ -134,8 +136,9 @@ void netxen_handle_port_int(struct netxen_adapter *adapter, u32 enable)
> if (adapter->enable_phy_interrupts)
> adapter->enable_phy_interrupts(adapter);
> }
> +#endif /* 0 */
>
> -void netxen_nic_isr_other(struct netxen_adapter *adapter)
> +static void netxen_nic_isr_other(struct netxen_adapter *adapter)
> {
> int portno = adapter->portnum;
> u32 val, linkup, qg_linksup;
> diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
> index a80f0cd..d0d1f05 100644
> --- a/drivers/net/netxen/netxen_nic_main.c
> +++ b/drivers/net/netxen/netxen_nic_main.c
> @@ -89,8 +89,8 @@ MODULE_DEVICE_TABLE(pci, netxen_pci_tbl);
> struct workqueue_struct *netxen_workq;
> static void netxen_watchdog(unsigned long);
>
> -static inline void netxen_nic_update_cmd_producer(struct netxen_adapter *adapter,
> - uint32_t crb_producer)
> +static void netxen_nic_update_cmd_producer(struct netxen_adapter *adapter,
> + uint32_t crb_producer)
> {
> switch (adapter->portnum) {
> case 0:
> @@ -118,8 +118,8 @@ static inline void netxen_nic_update_cmd_producer(struct netxen_adapter *adapter
> }
> }
>
> -static inline void netxen_nic_update_cmd_consumer(struct netxen_adapter *adapter,
> - u32 crb_consumer)
> +static void netxen_nic_update_cmd_consumer(struct netxen_adapter *adapter,
> + u32 crb_consumer)
> {
> switch (adapter->portnum) {
> case 0:
> @@ -148,7 +148,6 @@ static inline void netxen_nic_update_cmd_consumer(struct netxen_adapter *adapter
> }
>
> #define ADAPTER_LIST_SIZE 12
> -int netxen_cards_found;
>
> static void netxen_nic_disable_int(struct netxen_adapter *adapter)
> {
> diff --git a/drivers/net/netxen/netxen_nic_niu.c b/drivers/net/netxen/netxen_nic_niu.c
> index 5b9e1b3..94e096c 100644
> --- a/drivers/net/netxen/netxen_nic_niu.c
> +++ b/drivers/net/netxen/netxen_nic_niu.c
> @@ -40,7 +40,7 @@
>
> static long phy_lock_timeout = 100000000;
>
> -static inline int phy_lock(struct netxen_adapter *adapter)
> +static int phy_lock(struct netxen_adapter *adapter)
> {
> int i;
> int done = 0, timeout = 0;
> @@ -68,7 +68,7 @@ static inline int phy_lock(struct netxen_adapter *adapter)
> return 0;
> }
>
> -static inline int phy_unlock(struct netxen_adapter *adapter)
> +static int phy_unlock(struct netxen_adapter *adapter)
> {
> readl(pci_base_offset(adapter, NETXEN_PCIE_REG(PCIE_SEM3_UNLOCK)));
>
> @@ -300,13 +300,15 @@ int netxen_niu_gbe_disable_phy_interrupts(struct netxen_adapter *adapter)
> return result;
> }
>
> +#if 0
> int netxen_niu_xgbe_clear_phy_interrupts(struct netxen_adapter *adapter)
> {
> netxen_crb_writelit_adapter(adapter, NETXEN_NIU_ACTIVE_INT, -1);
> return 0;
> }
> +#endif /* 0 */
>
> -int netxen_niu_gbe_clear_phy_interrupts(struct netxen_adapter *adapter)
> +static int netxen_niu_gbe_clear_phy_interrupts(struct netxen_adapter *adapter)
> {
> int result = 0;
> if (0 !=
> @@ -322,8 +324,8 @@ int netxen_niu_gbe_clear_phy_interrupts(struct netxen_adapter *adapter)
> * netxen_niu_gbe_set_mii_mode- Set 10/100 Mbit Mode for GbE MAC
> *
> */
> -void netxen_niu_gbe_set_mii_mode(struct netxen_adapter *adapter,
> - int port, long enable)
> +static void netxen_niu_gbe_set_mii_mode(struct netxen_adapter *adapter,
> + int port, long enable)
> {
> netxen_crb_writelit_adapter(adapter, NETXEN_NIU_MODE, 0x2);
> netxen_crb_writelit_adapter(adapter, NETXEN_NIU_GB_MAC_CONFIG_0(port),
> @@ -360,8 +362,8 @@ void netxen_niu_gbe_set_mii_mode(struct netxen_adapter *adapter,
> /*
> * netxen_niu_gbe_set_gmii_mode- Set GbE Mode for GbE MAC
> */
> -void netxen_niu_gbe_set_gmii_mode(struct netxen_adapter *adapter,
> - int port, long enable)
> +static void netxen_niu_gbe_set_gmii_mode(struct netxen_adapter *adapter,
> + int port, long enable)
> {
> netxen_crb_writelit_adapter(adapter, NETXEN_NIU_MODE, 0x2);
> netxen_crb_writelit_adapter(adapter, NETXEN_NIU_GB_MAC_CONFIG_0(port),
> @@ -464,6 +466,7 @@ int netxen_niu_xg_init_port(struct netxen_adapter *adapter, int port)
> return 0;
> }
>
> +#if 0
> /*
> * netxen_niu_gbe_handle_phy_interrupt - Handles GbE PHY interrupts
> * @param enable 0 means don't enable the port
> @@ -559,13 +562,14 @@ int netxen_niu_gbe_handle_phy_interrupt(struct netxen_adapter *adapter,
> }
> return result;
> }
> +#endif /* 0 */
>
> /*
> * Return the current station MAC address.
> * Note that the passed-in value must already be in network byte order.
> */
> -int netxen_niu_macaddr_get(struct netxen_adapter *adapter,
> - netxen_ethernet_macaddr_t * addr)
> +static int netxen_niu_macaddr_get(struct netxen_adapter *adapter,
> + netxen_ethernet_macaddr_t * addr)
> {
> u32 stationhigh;
> u32 stationlow;
> @@ -636,6 +640,7 @@ int netxen_niu_macaddr_set(struct netxen_adapter *adapter,
> return 0;
> }
>
> +#if 0
> /* Enable a GbE interface */
> int netxen_niu_enable_gbe_port(struct netxen_adapter *adapter,
> int port, netxen_niu_gbe_ifmode_t mode)
> @@ -713,6 +718,7 @@ int netxen_niu_enable_gbe_port(struct netxen_adapter *adapter,
> return -EIO;
> return 0;
> }
> +#endif /* 0 */
>
> /* Disable a GbE interface */
> int netxen_niu_disable_gbe_port(struct netxen_adapter *adapter)
> @@ -853,6 +859,7 @@ int netxen_niu_xg_macaddr_set(struct netxen_adapter *adapter,
> return 0;
> }
>
> +#if 0
> /*
> * Return the current station MAC address.
> * Note that the passed-in value must already be in network byte order.
> @@ -883,6 +890,7 @@ int netxen_niu_xg_macaddr_get(struct netxen_adapter *adapter,
>
> return 0;
> }
> +#endif /* 0 */
>
> int netxen_niu_xg_set_promiscuous_mode(struct netxen_adapter *adapter,
> netxen_niu_prom_mode_t mode)
> diff --git a/drivers/net/netxen/netxen_nic_phan_reg.h b/drivers/net/netxen/netxen_nic_phan_reg.h
> index 10fe6fa..a6c28de 100644
> --- a/drivers/net/netxen/netxen_nic_phan_reg.h
> +++ b/drivers/net/netxen/netxen_nic_phan_reg.h
> @@ -165,14 +165,7 @@ struct netxen_recv_crb {
> u32 crb_status_ring_size;
> };
>
> -#if defined(DEFINE_GLOBAL_RECV_CRB)
> -#else
> extern struct netxen_recv_crb recv_crb_registers[];
> -extern u64 ctx_addr_sig_regs[][3];
> -#endif /* DEFINE_GLOBAL_RECEIVE_CRB */
> -#define CRB_CTX_ADDR_REG_LO(FUNC_ID) (ctx_addr_sig_regs[FUNC_ID][0])
> -#define CRB_CTX_ADDR_REG_HI(FUNC_ID) (ctx_addr_sig_regs[FUNC_ID][2])
> -#define CRB_CTX_SIGNATURE_REG(FUNC_ID) (ctx_addr_sig_regs[FUNC_ID][1])
>
> /*
> * Temperature control.
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Anton Vorontsov @ 2007-11-08 18:39 UTC (permalink / raw)
To: Kim Phillips; +Cc: Li Yang, Kumar Gala, netdev, linuxppc-dev, paulus, jgarzik
In-Reply-To: <20071108121508.39a65c33.kim.phillips@freescale.com>
On Thu, Nov 08, 2007 at 12:15:08PM -0600, Kim Phillips wrote:
> On Thu, 8 Nov 2007 17:16:11 +0300
> Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> > On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> > > Hello all,
> > >
> > > the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> > > according to erratum #2 (erratum text included below). Basically the
> > > most intrusive part is the addition of two new RGMII Internal Delay
> > > modes; one for TX delay only, and the other for RX delay only (i.e, not
> > > both at the same time).
> > >
> > > Please review, and since this affects both netdev and powerpc trees,
> > > one maintainer should ack them for the other to push upstream (i.e,
> > > Kumar acks them, and Leo picks them up to go through netdev or the
> > > other way around; either way is fine with me). I'm hoping they're
> > > trivial enough to go in 2.6.24.
> > >
> > > Depending on how the review goes, a follow-on patch to u-boot will be
> > > sent out that fixes up the phy-connection-type in the device tree (from
> > > "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).
> >
> > I've upgraded CPU to rev2.1, board rev0.3.
> >
> thanks for testing this. I tested these patches on a "pilot assy 0.3".
Same here.
> > Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
> > the results:
> >
> > If I use -rxid, then geth not able to transmit anything.
> > With -txid geth not able to receive anything.
> >
> > With just -id everything works fine though...
> >
> >
> > Maybe there should be another condition, in addition to cpu rev2.1?
> >
> the errata simply states 'pilot boards', but we can probably modify
> u-boot to look at the cpu rev and the board rev (BCSR 12).
>
> My bcsr12 looks like:
>
> => md.b f800000c 1
> f800000c: 10 .
>
> what is yours?
=> md.b f800000c 1
f800000c: 10 .
:-/
U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
root@b1:~# cat /proc/cpuinfo
processor : 0
cpu : e300c1
clock : 528.000000MHz
revision : 3.1 (pvr 8083 0031)
bogomips : 131.58
timebase : 66000000
platform : MPC836x MDS
+ /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
+ svid = mfspr(SPRN_SVR);
+ if (svid == 0x80480021) {
^^ that branch executes on the board I'm testing.
> If it's something like 0x03, the u-boot patch will probably look like:
>
> if ((bcsr[12] == 0x10) &&
> (immr->sysconf.spridr == SPR_8360_REV21 ||
> immr->sysconf.spridr == SPR_8360E_REV21))
> /* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> ...
>
> but these linux patches would remain the same (the clk and data delay
> settings for the UCC's are still valid; it's just the PHY config
> that is triggering your problem from what I can tell).
Yup, most likely this is not UCC specific, but PHY. For some reason
delays making harm here...
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Why does a connect to IPv6 LLA address fail ?
From: Karsten Keil @ 2007-11-08 18:32 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: Andreas Gruenbacher, Jiri Bohac, netdev, yoshfuji, kkeil
In-Reply-To: <47335258.4000806@hp.com>
On Thu, Nov 08, 2007 at 01:15:52PM -0500, Vlad Yasevich wrote:
> Andreas Gruenbacher wrote:
> > On Wednesday 07 November 2007 20:42, Vlad Yasevich wrote:
> >> The reason is that 2 different hosts may have the same link-local
> >> address as long as they are on different links. If the sender is
> >> connected to both links then it may send the packet to the wrong
> >> destination.
> >
> > Good point.
> >
> > What's confusing is that connect(2) fails even if the host itself has the
> > specified address. This isn't necessary.
>
> Yes and no. Since linux doesn't have the concept of default zone, we have
> to fail, because from the perspective of the kernel, the address was not
> fully specified. OTOH, since this is our address, we 'could' have all
> the info.
>
> The problem is that this verification happens before we hit the routing logic.
> It's an explicit check the if the sin6_scope_id is not set and we are not bound
> to an interface, it's an error.
>
OK I run into this issue while running the TAHI testsuite. The test is as
follows:
Check 03:
DNS Address: fec0::9
Candidate Source Addresses: fec0::1(SS) or LLA(LS)
Destination Address List: 3fff::2(GS) or fe80::2(LS)
Result: fe80::2 (src LLA) then 3fff::2 (src fec0::1)
Scope(fe80::2) = Scope(LLA) and Scope(3fff::2) <> Scope(fec0::1), then prefer fe80::2
the nameserver send following answer for the query:
| | | | DNS_Question (length:21)
| | | | | DNS_QuestionEntry (length:21)
| | | | | | Name = server.tahi.org.
| | | | | | Type = 28 (AAAA)
| | | | | | Class = 1
| | | | DNS_Answer (length:86)
| | | | | DNS_RR_AAAA (length:43)
| | | | | | Name = server.tahi.org.
| | | | | | Type = 28
| | | | | | Class = 1
| | | | | | TTL = 0
| | | | | | Length = 16
| | | | | | Address = 3fff::2
| | | | | DNS_RR_AAAA (length:43)
| | | | | | Name = server.tahi.org.
| | | | | | Type = 28
| | | | | | Class = 1
| | | | | | TTL = 0
| | | | | | Length = 16
| | | | | | Address = fe80::2
So how we should handle this issue, claim that the test is wrong, the test
should not use LLA for this ?
--
Karsten Keil
SuSE Labs
ISDN and VOIP development
SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)
^ permalink raw reply
* [PATCH] Fix e100 on systems that have cache incoherent DMA
From: Auke Kok @ 2007-11-08 18:17 UTC (permalink / raw)
To: jeff, akpm
Cc: netdev, dacker, auke-jan.h.kok, jesse.brandeburg, miltonm,
e1000-devel
From: David Acker <dacker@roinet.com>
On the systems that have cache incoherent DMA, including ARM, there
is a race condition between software allocating a new receive buffer
and hardware writing into a buffer. The two race on touching the last
Receive Frame Descriptor (RFD). It has its el-bit set and its next
link equal to 0. When hardware encounters this buffer it attempts to
write data to it and then update Status Word bits and Actual Count in
the RFD. At the same time software may try to clear the el-bit and
set the link address to a new buffer.
Since the entire RFD is once cache-line, the two write operations can
collide. This can lead to the receive unit stalling or interpreting
random memory as its receive area.
The fix is to set the el-bit on and the size to 0 on the next to last
buffer in the chain. When the hardware encounters this buffer it stops
and does not write to it at all. The hardware issues an RNR interrupt
with the receive unit in the No Resources state. Software can write
to the tail of the list because it knows hardware will stop on the
previous descriptor that was marked as the end of list.
Once it has a new next to last buffer prepared, it can clear the el-bit
and set the size on the previous one. The race on this buffer is safe
since the link already points to a valid next buffer and the software
can handle the race setting the size (assuming aligned 16 bit writes
are atomic with respect to the DMA read). If the hardware sees the
el-bit cleared without the size set, it will move on to the next buffer
and skip this one. If it sees the size set but the el-bit still set,
it will complete that buffer and then RNR interrupt and wait.
Signed-off-by: David Acker <dacker@roinet.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e100.c | 128 ++++++++++++++++++++++++++++++++++++++++------------
1 files changed, 99 insertions(+), 29 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 3dbaec6..2153058 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -106,6 +106,13 @@
* the RFD, the RFD must be dma_sync'ed to maintain a consistent
* view from software and hardware.
*
+ * In order to keep updates to the RFD link field from colliding with
+ * hardware writes to mark packets complete, we use the feature that
+ * hardware will not write to a size 0 descriptor and mark the previous
+ * packet as end-of-list (EL). After updating the link, we remove EL
+ * and only then restore the size such that hardware may use the
+ * previous-to-end RFD.
+ *
* Under typical operation, the receive unit (RU) is start once,
* and the controller happily fills RFDs as frames arrive. If
* replacement RFDs cannot be allocated, or the RU goes non-active,
@@ -281,6 +288,7 @@ struct csr {
};
enum scb_status {
+ rus_no_res = 0x08,
rus_ready = 0x10,
rus_mask = 0x3C,
};
@@ -952,7 +960,7 @@ static void e100_get_defaults(struct nic *nic)
((nic->mac >= mac_82558_D101_A4) ? cb_cid : cb_i));
/* Template for a freshly allocated RFD */
- nic->blank_rfd.command = cpu_to_le16(cb_el);
+ nic->blank_rfd.command = 0;
nic->blank_rfd.rbd = 0xFFFFFFFF;
nic->blank_rfd.size = cpu_to_le16(VLAN_ETH_FRAME_LEN);
@@ -1791,15 +1799,12 @@ static int e100_rx_alloc_skb(struct nic *nic, struct rx *rx)
}
/* Link the RFD to end of RFA by linking previous RFD to
- * this one, and clearing EL bit of previous. */
+ * this one. We are safe to touch the previous RFD because
+ * it is protected by the before last buffer's el bit being set */
if(rx->prev->skb) {
struct rfd *prev_rfd = (struct rfd *)rx->prev->skb->data;
put_unaligned(cpu_to_le32(rx->dma_addr),
(u32 *)&prev_rfd->link);
- wmb();
- prev_rfd->command &= ~cpu_to_le16(cb_el);
- pci_dma_sync_single_for_device(nic->pdev, rx->prev->dma_addr,
- sizeof(struct rfd), PCI_DMA_TODEVICE);
}
return 0;
@@ -1824,8 +1829,19 @@ static int e100_rx_indicate(struct nic *nic, struct rx *rx,
DPRINTK(RX_STATUS, DEBUG, "status=0x%04X\n", rfd_status);
/* If data isn't ready, nothing to indicate */
- if(unlikely(!(rfd_status & cb_complete)))
+ if (unlikely(!(rfd_status & cb_complete))) {
+ /* If the next buffer has the el bit, but we think the receiver
+ * is still running, check to see if it really stopped while
+ * we had interrupts off.
+ * This allows for a fast restart without re-enabling
+ * interrupts */
+ if ((le16_to_cpu(rfd->command) & cb_el) &&
+ (RU_RUNNING == nic->ru_running))
+
+ if (readb(&nic->csr->scb.status) & rus_no_res)
+ nic->ru_running = RU_SUSPENDED;
return -ENODATA;
+ }
/* Get actual data size */
actual_size = le16_to_cpu(rfd->actual_size) & 0x3FFF;
@@ -1836,9 +1852,18 @@ static int e100_rx_indicate(struct nic *nic, struct rx *rx,
pci_unmap_single(nic->pdev, rx->dma_addr,
RFD_BUF_LEN, PCI_DMA_FROMDEVICE);
- /* this allows for a fast restart without re-enabling interrupts */
- if(le16_to_cpu(rfd->command) & cb_el)
+ /* If this buffer has the el bit, but we think the receiver
+ * is still running, check to see if it really stopped while
+ * we had interrupts off.
+ * This allows for a fast restart without re-enabling interrupts.
+ * This can happen when the RU sees the size change but also sees
+ * the el bit set. */
+ if ((le16_to_cpu(rfd->command) & cb_el) &&
+ (RU_RUNNING == nic->ru_running)) {
+
+ if (readb(&nic->csr->scb.status) & rus_no_res)
nic->ru_running = RU_SUSPENDED;
+ }
/* Pull off the RFD and put the actual data (minus eth hdr) */
skb_reserve(skb, sizeof(struct rfd));
@@ -1870,31 +1895,30 @@ static void e100_rx_clean(struct nic *nic, unsigned int *work_done,
unsigned int work_to_do)
{
struct rx *rx;
- int restart_required = 0;
- struct rx *rx_to_start = NULL;
-
- /* are we already rnr? then pay attention!!! this ensures that
- * the state machine progression never allows a start with a
- * partially cleaned list, avoiding a race between hardware
- * and rx_to_clean when in NAPI mode */
- if(RU_SUSPENDED == nic->ru_running)
- restart_required = 1;
+ int restart_required = 0, err = 0;
+ struct rx *old_before_last_rx, *new_before_last_rx;
+ struct rfd *old_before_last_rfd, *new_before_last_rfd;
/* Indicate newly arrived packets */
for(rx = nic->rx_to_clean; rx->skb; rx = nic->rx_to_clean = rx->next) {
- int err = e100_rx_indicate(nic, rx, work_done, work_to_do);
- if(-EAGAIN == err) {
- /* hit quota so have more work to do, restart once
- * cleanup is complete */
- restart_required = 0;
+ err = e100_rx_indicate(nic, rx, work_done, work_to_do);
+ /* Hit quota or no more to clean */
+ if (-EAGAIN == err || -ENODATA == err)
break;
- } else if(-ENODATA == err)
- break; /* No more to clean */
}
- /* save our starting point as the place we'll restart the receiver */
- if(restart_required)
- rx_to_start = nic->rx_to_clean;
+
+ /* On EAGAIN, hit quota so have more work to do, restart once
+ * cleanup is complete.
+ * Else, are we already rnr? then pay attention!!! this ensures that
+ * the state machine progression never allows a start with a
+ * partially cleaned list, avoiding a race between hardware
+ * and rx_to_clean when in NAPI mode */
+ if (-EAGAIN != err && RU_SUSPENDED == nic->ru_running)
+ restart_required = 1;
+
+ old_before_last_rx = nic->rx_to_use->prev->prev;
+ old_before_last_rfd = (struct rfd *)old_before_last_rx->skb->data;
/* Alloc new skbs to refill list */
for(rx = nic->rx_to_use; !rx->skb; rx = nic->rx_to_use = rx->next) {
@@ -1902,10 +1926,42 @@ static void e100_rx_clean(struct nic *nic, unsigned int *work_done,
break; /* Better luck next time (see watchdog) */
}
+ new_before_last_rx = nic->rx_to_use->prev->prev;
+ if (new_before_last_rx != old_before_last_rx) {
+ /* Set the el-bit on the buffer that is before the last buffer.
+ * This lets us update the next pointer on the last buffer
+ * without worrying about hardware touching it.
+ * We set the size to 0 to prevent hardware from touching this
+ * buffer.
+ * When the hardware hits the before last buffer with el-bit
+ * and size of 0, it will RNR interrupt, the RUS will go into
+ * the No Resources state. It will not complete nor write to
+ * this buffer. */
+ new_before_last_rfd =
+ (struct rfd *)new_before_last_rx->skb->data;
+ new_before_last_rfd->size = 0;
+ new_before_last_rfd->command |= cpu_to_le16(cb_el);
+ pci_dma_sync_single_for_device(nic->pdev,
+ new_before_last_rx->dma_addr, sizeof(struct rfd),
+ PCI_DMA_TODEVICE);
+
+ /* Now that we have a new stopping point, we can clear the old
+ * stopping point. We must sync twice to get the proper
+ * ordering on the hardware side of things. */
+ old_before_last_rfd->command &= ~cpu_to_le16(cb_el);
+ pci_dma_sync_single_for_device(nic->pdev,
+ old_before_last_rx->dma_addr, sizeof(struct rfd),
+ PCI_DMA_TODEVICE);
+ old_before_last_rfd->size = cpu_to_le16(VLAN_ETH_FRAME_LEN);
+ pci_dma_sync_single_for_device(nic->pdev,
+ old_before_last_rx->dma_addr, sizeof(struct rfd),
+ PCI_DMA_TODEVICE);
+ }
+
if(restart_required) {
// ack the rnr?
writeb(stat_ack_rnr, &nic->csr->scb.stat_ack);
- e100_start_receiver(nic, rx_to_start);
+ e100_start_receiver(nic, nic->rx_to_clean);
if(work_done)
(*work_done)++;
}
@@ -1937,6 +1993,7 @@ static int e100_rx_alloc_list(struct nic *nic)
{
struct rx *rx;
unsigned int i, count = nic->params.rfds.count;
+ struct rfd *before_last;
nic->rx_to_use = nic->rx_to_clean = NULL;
nic->ru_running = RU_UNINITIALIZED;
@@ -1952,6 +2009,19 @@ static int e100_rx_alloc_list(struct nic *nic)
return -ENOMEM;
}
}
+ /* Set the el-bit on the buffer that is before the last buffer.
+ * This lets us update the next pointer on the last buffer without
+ * worrying about hardware touching it.
+ * We set the size to 0 to prevent hardware from touching this buffer.
+ * When the hardware hits the before last buffer with el-bit and size
+ * of 0, it will RNR interrupt, the RU will go into the No Resources
+ * state. It will not complete nor write to this buffer. */
+ rx = nic->rxs->prev->prev;
+ before_last = (struct rfd *)rx->skb->data;
+ before_last->command |= cpu_to_le16(cb_el);
+ before_last->size = 0;
+ pci_dma_sync_single_for_device(nic->pdev, rx->dma_addr,
+ sizeof(struct rfd), PCI_DMA_TODEVICE);
nic->rx_to_use = nic->rx_to_clean = nic->rxs;
nic->ru_running = RU_SUSPENDED;
^ permalink raw reply related
* Re: Why does a connect to IPv6 LLA address fail ?
From: Vlad Yasevich @ 2007-11-08 18:15 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: Jiri Bohac, netdev, yoshfuji, kkeil
In-Reply-To: <200711081901.59334.agruen@suse.de>
Andreas Gruenbacher wrote:
> On Wednesday 07 November 2007 20:42, Vlad Yasevich wrote:
>> The reason is that 2 different hosts may have the same link-local
>> address as long as they are on different links. If the sender is
>> connected to both links then it may send the packet to the wrong
>> destination.
>
> Good point.
>
> What's confusing is that connect(2) fails even if the host itself has the
> specified address. This isn't necessary.
Yes and no. Since linux doesn't have the concept of default zone, we have
to fail, because from the perspective of the kernel, the address was not
fully specified. OTOH, since this is our address, we 'could' have all
the info.
The problem is that this verification happens before we hit the routing logic.
It's an explicit check the if the sin6_scope_id is not set and we are not bound
to an interface, it's an error.
>
> What's even more confusing is that the kernel doesn't seem to honor the
> interface in all cases: with
> fe80::20f:20ff:fe3b:e9c3 on eth0 and
> ::1 on lo,
> I get the following:
>
> ping6 fe80::20f:20ff:fe3b:e9c3 fails with EINVAL
> ping6 fe80::20f:20ff:fe3b:e9c3%eth0 succeeds
Yes, but if you run a capture, you'll see the packet on loopback. That's
because you have a route to this address.
> ping6 fe80::20f:20ff:fe3b:e9c3%lo succeeds
Yes, same thing. Routing code takes care of it.
>
> At least the last ping should fail, shouldn't it?
No, because both pings really go over loopback. You are on the same system
and have 'local' routes for those addresses:
ip -6 r l t local
>
>> A different and some might say 'better' alternative is to define a
>> default link. Thus when the zone id is not specified the default is used.
>> This will work fine for link-scoped addresses. A default zone would also
>> need to be defined for other scopes as well. That's just one idea.
>
> I think at least for host with only one link (in addition to loopback),
> selecting that link for non-local addresses would make sense.
>
Yes, you could do that. Or you can push the interface check to the routing code
and do some logic to see if you can "select" an interface.
-vlad
^ permalink raw reply
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Kim Phillips @ 2007-11-08 18:15 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, linuxppc-dev, paulus, Li Yang, jgarzik
In-Reply-To: <20071108141611.GA5770@localhost.localdomain>
On Thu, 8 Nov 2007 17:16:11 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> > Hello all,
> >
> > the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> > according to erratum #2 (erratum text included below). Basically the
> > most intrusive part is the addition of two new RGMII Internal Delay
> > modes; one for TX delay only, and the other for RX delay only (i.e, not
> > both at the same time).
> >
> > Please review, and since this affects both netdev and powerpc trees,
> > one maintainer should ack them for the other to push upstream (i.e,
> > Kumar acks them, and Leo picks them up to go through netdev or the
> > other way around; either way is fine with me). I'm hoping they're
> > trivial enough to go in 2.6.24.
> >
> > Depending on how the review goes, a follow-on patch to u-boot will be
> > sent out that fixes up the phy-connection-type in the device tree (from
> > "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).
>
> I've upgraded CPU to rev2.1, board rev0.3.
>
thanks for testing this. I tested these patches on a "pilot assy 0.3".
> Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
> the results:
>
> If I use -rxid, then geth not able to transmit anything.
> With -txid geth not able to receive anything.
>
> With just -id everything works fine though...
>
>
> Maybe there should be another condition, in addition to cpu rev2.1?
>
the errata simply states 'pilot boards', but we can probably modify
u-boot to look at the cpu rev and the board rev (BCSR 12).
My bcsr12 looks like:
=> md.b f800000c 1
f800000c: 10 .
what is yours?
If it's something like 0x03, the u-boot patch will probably look like:
if ((bcsr[12] == 0x10) &&
(immr->sysconf.spridr == SPR_8360_REV21 ||
immr->sysconf.spridr == SPR_8360E_REV21))
/* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
...
but these linux patches would remain the same (the clk and data delay
settings for the UCC's are still valid; it's just the PHY config
that is triggering your problem from what I can tell).
Thanks,
Kim
> > mpc8360 rev 2.1 erratum #2:
> > -----------
> > Recommended AC timings for chip 8360Rev2.1 UCC ETH RGMII when working
> > with Rev Pilot MDS for proper RGMII operation:
> >
> > IMMR_BASE + 0x14A8[4:5] = 11 (clk delay for UCC 2)
> > IMMR_BASE + 0x14A8[18:19] = 11 (clk delay for UCC 1)
> > IMMR_BASE + 0x14AC[20:27] = 10101010 (data delay for both UCC's)
> >
> > The Phy (Marvell 88e1111) should be configured NOT to work with RGMII
> > delay for TxD.
^ permalink raw reply
* Re: Why does a connect to IPv6 LLA address fail ?
From: Andreas Gruenbacher @ 2007-11-08 18:01 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: Jiri Bohac, netdev, yoshfuji, kkeil
In-Reply-To: <4732151B.70309@hp.com>
On Wednesday 07 November 2007 20:42, Vlad Yasevich wrote:
> The reason is that 2 different hosts may have the same link-local
> address as long as they are on different links. If the sender is
> connected to both links then it may send the packet to the wrong
> destination.
Good point.
What's confusing is that connect(2) fails even if the host itself has the
specified address. This isn't necessary.
What's even more confusing is that the kernel doesn't seem to honor the
interface in all cases: with
fe80::20f:20ff:fe3b:e9c3 on eth0 and
::1 on lo,
I get the following:
ping6 fe80::20f:20ff:fe3b:e9c3 fails with EINVAL
ping6 fe80::20f:20ff:fe3b:e9c3%eth0 succeeds
ping6 fe80::20f:20ff:fe3b:e9c3%lo succeeds
At least the last ping should fail, shouldn't it?
> A different and some might say 'better' alternative is to define a
> default link. Thus when the zone id is not specified the default is used.
> This will work fine for link-scoped addresses. A default zone would also
> need to be defined for other scopes as well. That's just one idea.
I think at least for host with only one link (in addition to loopback),
selecting that link for non-local addresses would make sense.
Thanks,
Andreas
^ permalink raw reply
* Re: Please pull 'fixes-jgarzik' branch of wireless-2.6 (3rd time is the charm?)
From: Jeff Garzik @ 2007-11-08 17:53 UTC (permalink / raw)
To: John W. Linville
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20071108142626.GH11957-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On Thu, Nov 08, 2007 at 09:26:26AM -0500, John W. Linville wrote:
> Jeff,
>
> OK, I think things are settled now. I apologize for the confusion.
>
> These are fixes intended for 2.6.24. Please note that three of the
> patches from Michael Buesch in the list below were already sent to
> you directed for 2.6.25. Upon further review, I think they belong in
> 2.6.24 instead. I cherry-picked them, so I'm fairly certain git will
> be smart enough to drop them from your 2.6.25 branch when you rebase.
>
> Please let me know if there are any problems.
>
> Thanks!
>
> John
>
> ---
>
> Individual patches are available here:
>
> http://www.kernel.org/pub//linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/
>
pulled into #upstream-fixes; please check the merge in #upstream
^ permalink raw reply
* Re: ax88796: add superh to kconfig dependencies
From: Jeff Garzik @ 2007-11-08 17:47 UTC (permalink / raw)
To: Magnus Damm; +Cc: netdev, lethal, ben-linux, akpm
In-Reply-To: <20071108073105.3996.70418.sendpatchset@clockwork.opensource.se>
On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote:
> ax88796: add superh to kconfig dependencies
>
> This patch adds sh architecture support to the ax88796 kconfig.
>
> Signed-off-by: Magnus Damm <damm@igel.co.jp>
> ---
>
> This patch was posted about a month ago but never picked up:
> http://www.mail-archive.com/netdev@vger.kernel.org/msg50018.html
> The rest of the sh support is already included in rc1. Please apply.
>
> drivers/net/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied
^ permalink raw reply
* Re: [PATCH 1/2] qla3xxx: bugfix: Move link state machine into a worker thread
From: Jeff Garzik @ 2007-11-08 17:47 UTC (permalink / raw)
To: Ron Mercer; +Cc: netdev
In-Reply-To: <1194472747331-git-send-email-ron.mercer@qlogic.com>
On Wed, Nov 07, 2007 at 01:59:06PM -0800, Ron Mercer wrote:
> The link state machine requires access to some resources that
> are shared with the iSCSI function on the chip. (See iSCSI
> driver at drivers/scsi/qla4xxx) If the interface is being
> up/downed at a rapid pace this driver may need to sleep
> waiting to get access to the common resources. For this we
> are moving the state machine to run as a work thread.
>
> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
> ---
> drivers/net/qla3xxx.c | 27 +++++++++++++--------------
> drivers/net/qla3xxx.h | 1 +
> 2 files changed, 14 insertions(+), 14 deletions(-)
applied 1-2
^ permalink raw reply
* Re: [PATCH 1/2] pasemi_mac: Don't set replace-source-address descriptor bits
From: Jeff Garzik @ 2007-11-08 17:47 UTC (permalink / raw)
To: Olof Johansson; +Cc: jgarzik, netdev, linuxppc-dev
In-Reply-To: <20071107042039.GD22637@lixom.net>
On Tue, Nov 06, 2007 at 10:20:39PM -0600, Olof Johansson wrote:
> Don't use the "replace source address with local MAC address" bits, since
> it causes problems on some variations of the hardware due to an erratum.
>
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
applied 1-2
^ permalink raw reply
* Re: [PATCH 1/2] bonding: fix rtnl locking merge error
From: Jeff Garzik @ 2007-11-08 17:47 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev, jgarzik
In-Reply-To: <11943848132752-git-send-email-fubar@us.ibm.com>
On Tue, Nov 06, 2007 at 01:33:28PM -0800, Jay Vosburgh wrote:
> Looks like I incorrectly merged one of the rtnl lock changes,
> so that one function, bonding_show_active_slave, held rtnl but didn't
> release it, and another, bonding_store_active_slave, never held rtnl but
> did release it.
>
> Fixed so the first function doesn't mess with rtnl, and the
> second correctly acquires and releases rtnl.
>
> Bug reported by Moni Shoua <monis@voltaire.com>
>
>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
applied 1-2
^ permalink raw reply
* Re: [PATCH] sky2: netpoll on port 0 only
From: Jeff Garzik @ 2007-11-08 17:47 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jeff Garzik, David S. Miller, netdev
In-Reply-To: <20071106114540.75ec66ab@freepuppy.rosehill>
On Tue, Nov 06, 2007 at 11:45:40AM -0800, Stephen Hemminger wrote:
> Netpoll will only work on port 0 because of the restrictive
> relationship between NAPI and netpoll.
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
applied
^ permalink raw reply
* Re: 2.6.24-rc1-gb4f5550 oops
From: Grant Wilson @ 2007-11-08 17:22 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: lkml, Andrew Morton, netdev
In-Reply-To: <200711081653.11226.rjw@sisk.pl>
On Thu, 8 Nov 2007 16:53:10 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> On Thursday, 8 of November 2007, Grant Wilson wrote:
> > On Thu, 8 Nov 2007 01:06:21 +0100
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> >
> > > On Monday, 5 of November 2007, Grant Wilson wrote:
> > > > Hi,
> > > > I got this oops on 2.6.24-rc1-641-gb4f5550:
> > >
> > > (1) Is this reproducible?
> > > (2) Did it happen previously on your system?
> > >
> > > [18073.371126] Unable to handle kernel NULL pointer dereference at 0000000000000120 RIP:
> > > [18073.371134] [<ffffffff8023572e>] check_preempt_wakeup+0x6e/0x110
> >
> > This has now happened twice - the second time was last night when
> > running 2.6.24-rc2.
> >
> > Here's that second occurrence:
> >
[snip]
>
> Hmm.
>
> Please run "gdb vmlinux" and see what code corresponds to
> check_preempt_wakeup+0x6e in your kernel.
Dump of assembler code for function check_preempt_wakeup:
0xffffffff80232940 <check_preempt_wakeup+0>: push %rbp
0xffffffff80232941 <check_preempt_wakeup+1>: mov %rsp,%rbp
0xffffffff80232944 <check_preempt_wakeup+4>: sub $0x30,%rsp
0xffffffff80232948 <check_preempt_wakeup+8>: mov %r13,-0x18(%rbp)
0xffffffff8023294c <check_preempt_wakeup+12>: mov %rbx,-0x28(%rbp)
0xffffffff80232950 <check_preempt_wakeup+16>: mov %rsi,%r13
0xffffffff80232953 <check_preempt_wakeup+19>: mov %r12,-0x20(%rbp)
0xffffffff80232957 <check_preempt_wakeup+23>: mov %r14,-0x10(%rbp)
0xffffffff8023295b <check_preempt_wakeup+27>: mov %r15,-0x8(%rbp)
0xffffffff8023295f <check_preempt_wakeup+31>: cmpl $0x63,0x20(%rsi)
0xffffffff80232963 <check_preempt_wakeup+35>: mov 0x750(%rdi),%r14
0xffffffff8023296a <check_preempt_wakeup+42>: mov 0x168(%r14),%r12
0xffffffff80232971 <check_preempt_wakeup+49>: jle 0xffffffff80232a1c <check_preempt_wakeup+220>
0xffffffff80232977 <check_preempt_wakeup+55>: cmpl $0x3,0x17c(%rsi)
0xffffffff8023297e <check_preempt_wakeup+62>: je 0xffffffff802329f8 <check_preempt_wakeup+184>
0xffffffff80232980 <check_preempt_wakeup+64>: testb $0x10,0x593cb9(%rip) # 0xffffffff807c6640 <sysctl_sched_features>
0xffffffff80232987 <check_preempt_wakeup+71>: je 0xffffffff802329f8 <check_preempt_wakeup+184>
0xffffffff80232989 <check_preempt_wakeup+73>: cmp 0x168(%rsi),%r12
0xffffffff80232990 <check_preempt_wakeup+80>: lea 0x48(%r14),%rbx
0xffffffff80232994 <check_preempt_wakeup+84>: lea 0x48(%rsi),%rax
0xffffffff80232998 <check_preempt_wakeup+88>: je 0xffffffff802329be <check_preempt_wakeup+126>
0xffffffff8023299a <check_preempt_wakeup+90>: nopw 0x0(%rax,%rax,1)
0xffffffff802329a0 <check_preempt_wakeup+96>: mov 0x118(%rbx),%rbx
0xffffffff802329a7 <check_preempt_wakeup+103>: mov 0x118(%rax),%rax
0xffffffff802329ae <check_preempt_wakeup+110>: mov 0x120(%rax),%rdx
0xffffffff802329b5 <check_preempt_wakeup+117>: cmp %rdx,0x120(%rbx)
0xffffffff802329bc <check_preempt_wakeup+124>: jne 0xffffffff802329a0 <check_preempt_wakeup+96>
0xffffffff802329be <check_preempt_wakeup+126>: cmpq $0x400,(%rbx)
0xffffffff802329c5 <check_preempt_wakeup+133>: mov 0x40(%rbx),%r12
0xffffffff802329c9 <check_preempt_wakeup+137>: mov 0x40(%rax),%r15
0xffffffff802329cd <check_preempt_wakeup+141>: mov 0x593c81(%rip),%edi # 0xffffffff807c6654 <sysctl_sched_wakeup_granularity>
0xffffffff802329d3 <check_preempt_wakeup+147>: jne 0xffffffff80232a37 <check_preempt_wakeup+247>
0xffffffff802329d5 <check_preempt_wakeup+149>: sub %r15,%r12
0xffffffff802329d8 <check_preempt_wakeup+152>: cmp %r12,%rdi
0xffffffff802329db <check_preempt_wakeup+155>: jge 0xffffffff802329f8 <check_preempt_wakeup+184>
0xffffffff802329dd <check_preempt_wakeup+157>: testb $0x20,0x593c5c(%rip) # 0xffffffff807c6640 <sysctl_sched_features>
Cheers,
Grant
--
Running Linux 2.6.24-rc2 on x86_64
^ permalink raw reply
* [VLAN]: Allow setting mac address while device is up
From: Patrick McHardy @ 2007-11-08 17:20 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 211 bytes --]
This patch allows to change a VLAN device's MAC address while
the device is up. Doesn't seem worth to hold back until
2.6.25-rc since it can't break anything without actually
getting used (and it does work :))
[-- Attachment #2: 02.diff --]
[-- Type: text/x-patch, Size: 2668 bytes --]
[VLAN]: Allow setting mac address while device is up
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 5efb3597bba3b223fcf3690a88394064dded87ba
tree a15ae1c12bcdc1277c5a5096f420437c1ded7414
parent f6d0e3b654d36bd87016b0626464990f3fc57ca7
author Patrick McHardy <kaber@trash.net> Thu, 08 Nov 2007 18:12:20 +0100
committer Patrick McHardy <kaber@trash.net> Thu, 08 Nov 2007 18:12:20 +0100
net/8021q/vlan.c | 1 +
net/8021q/vlan.h | 1 +
net/8021q/vlan_dev.c | 26 ++++++++++++++++++++++++++
3 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index d80afec..dd4086b 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -376,6 +376,7 @@ void vlan_setup(struct net_device *new_dev)
new_dev->init = vlan_dev_init;
new_dev->open = vlan_dev_open;
new_dev->stop = vlan_dev_stop;
+ new_dev->set_mac_address = vlan_set_mac_address;
new_dev->set_multicast_list = vlan_dev_set_multicast_list;
new_dev->change_rx_flags = vlan_change_rx_flags;
new_dev->destructor = free_netdev;
diff --git a/net/8021q/vlan.h b/net/8021q/vlan.h
index cf4a80d..2cd1393 100644
--- a/net/8021q/vlan.h
+++ b/net/8021q/vlan.h
@@ -60,6 +60,7 @@ int vlan_dev_hwaccel_hard_start_xmit(struct sk_buff *skb, struct net_device *dev
int vlan_dev_change_mtu(struct net_device *dev, int new_mtu);
int vlan_dev_open(struct net_device* dev);
int vlan_dev_stop(struct net_device* dev);
+int vlan_set_mac_address(struct net_device *dev, void *p);
int vlan_dev_ioctl(struct net_device* dev, struct ifreq *ifr, int cmd);
void vlan_dev_set_ingress_priority(const struct net_device *dev,
u32 skb_prio, short vlan_prio);
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 1a1740a..7a36878 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -665,6 +665,32 @@ int vlan_dev_stop(struct net_device *dev)
return 0;
}
+int vlan_set_mac_address(struct net_device *dev, void *p)
+{
+ struct net_device *real_dev = VLAN_DEV_INFO(dev)->real_dev;
+ struct sockaddr *addr = p;
+ int err;
+
+ if (!is_valid_ether_addr(addr->sa_data))
+ return -EADDRNOTAVAIL;
+
+ if (!(dev->flags & IFF_UP))
+ goto out;
+
+ if (compare_ether_addr(addr->sa_data, real_dev->dev_addr)) {
+ err = dev_unicast_add(real_dev, addr->sa_data, ETH_ALEN);
+ if (err < 0)
+ return err;
+ }
+
+ if (compare_ether_addr(dev->dev_addr, real_dev->dev_addr))
+ dev_unicast_delete(real_dev, dev->dev_addr, ETH_ALEN);
+
+out:
+ memcpy(dev->dev_addr, addr->sa_data, ETH_ALEN);
+ return 0;
+}
+
int vlan_dev_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
{
struct net_device *real_dev = VLAN_DEV_INFO(dev)->real_dev;
^ permalink raw reply related
* [VLAN]: Don't synchronize addresses while the vlan device is down
From: Patrick McHardy @ 2007-11-08 17:19 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 01.diff --]
[-- Type: text/x-patch, Size: 1064 bytes --]
[VLAN]: Don't synchronize addresses while the vlan device is down
While the VLAN device is down, the unicast addresses are not configured
on the underlying device, so we shouldn't attempt to sync them.
Noticed by Dmitry Butskoy <buc@odusz.so-cdu.ru>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit f6d0e3b654d36bd87016b0626464990f3fc57ca7
tree 16ce232acdd1919e7ca42dc12b24f09f8d92f966
parent dbeeb816e805091e7cfc03baf36dc40b4adb2bbd
author Patrick McHardy <kaber@trash.net> Thu, 08 Nov 2007 17:34:43 +0100
committer Patrick McHardy <kaber@trash.net> Thu, 08 Nov 2007 17:34:43 +0100
net/8021q/vlan.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 3fe4fc8..d80afec 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -636,6 +636,10 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
if (!vlandev)
continue;
+ flgs = vlandev->flags;
+ if (!(flgs & IFF_UP))
+ continue;
+
vlan_sync_address(dev, vlandev);
}
break;
^ permalink raw reply related
* [PATCH] NET: Fix skb_truesize_check() assertion
From: Chuck Lever @ 2007-11-08 16:59 UTC (permalink / raw)
To: netdev
The intent of the assertion in skb_truesize_check() is to check
for skb->truesize being decremented too much by other code,
resulting in a wraparound below zero.
The type of the right side of the comparison causes the compiler to
promote the left side to an unsigned type, despite the presence of an
explicit type cast. This defeats the check for negativity.
Ensure both sides of the comparison are a signed type to prevent the
implicit type conversion.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
include/linux/skbuff.h | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 94e4991..91140fe 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -387,7 +387,9 @@ extern void skb_truesize_bug(struct sk_buff *skb);
static inline void skb_truesize_check(struct sk_buff *skb)
{
- if (unlikely((int)skb->truesize < sizeof(struct sk_buff) + skb->len))
+ int len = sizeof(struct sk_buff) + skb->len;
+
+ if (unlikely((int)skb->truesize < len))
skb_truesize_bug(skb);
}
^ permalink raw reply related
* Re: [PATCH] [NETFILTER] Consolidate nf_sockopt and compat_nf_sockopt v2
From: Patrick McHardy @ 2007-11-08 16:43 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: Linux Netdev List, devel
In-Reply-To: <473025DE.1000906@openvz.org>
Pavel Emelyanov wrote:
> Both lookup the nf_sockopt_ops object to call the get/set callbacks
> from, but they perform it in a completely similar way.
>
> Introduce the helper for finding the ops.
>
> Ported at the top of today's net-2.6 tree to resolve conflict
> with the patch from Alexey Dobriyan.
Applied, thanks Pavel.
^ permalink raw reply
* [PATCH] sky2: new pci id's
From: Stephen Hemminger @ 2007-11-08 16:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
Found a couple of more chips in the latest version of the vendor driver.
They are minor variations on existing chips, so please incorporate into
2.6.24.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/drivers/net/sky2.c 2007-11-07 22:45:02.000000000 -0800
+++ b/drivers/net/sky2.c 2007-11-07 22:46:29.000000000 -0800
@@ -121,6 +121,7 @@ static const struct pci_device_id sky2_i
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4353) }, /* 88E8039 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4354) }, /* 88E8040 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4356) }, /* 88EC033 */
+ { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4357) }, /* 88E8042 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x435A) }, /* 88E8048 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4360) }, /* 88E8052 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4361) }, /* 88E8050 */
@@ -134,6 +135,7 @@ static const struct pci_device_id sky2_i
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4369) }, /* 88EC042 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436A) }, /* 88E8058 */
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436B) }, /* 88E8071 */
+ { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436C) }, /* 88E8072 */
{ 0 }
};
^ permalink raw reply
* Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':
From: Randy Dunlap @ 2007-11-08 16:08 UTC (permalink / raw)
To: Adrian Bunk
Cc: David Brownell, David Miller, Toralf Förster, linux-kernel,
netdev
In-Reply-To: <20071108033010.GF26163@stusta.de>
On Thu, 8 Nov 2007 04:30:10 +0100 Adrian Bunk wrote:
> On Wed, Nov 07, 2007 at 11:52:32PM +0100, Adrian Bunk wrote:
> > On Wed, Nov 07, 2007 at 02:34:52PM -0800, David Brownell wrote:
> > > > > But on the other hand, it seems that only the ASIX code will work
> > > > > right; the DM9601 and MCS7830 Kconfig is different/wrong.
> > > >
> > > > I'm not seeing the problem.
> > > >
> > > > Which configuration will be handled wrongly?
> > >
> > > Notice how only the ASIX kconfig depended on NET_ETHERNET...
> > > since MII depends on NET_ETHERNET, and (last I knew) the
> > > reverse dependencies didn't capture the complete dependency
> > > tree, selecting only MII would leave out some stuff.
> >
> > Except for one s390 net driver (I'll check why it's doing this) the
> > NET_ETHERNET option does not influence what code is being generated -
> > it's just a Kconfig-internal option allowing to disable a huge bunch
> > of drivers at once.
>
> Damn, I shouldn't have only grep'ed under drivers/.
>
> @davem:
>
> Please look at net/ipv4/arp.c:arp_process()
>
> Am I right that CONFIG_NET_ETHERNET=n and CONFIG_NETDEV_1000=y or
> CONFIG_NETDEV_10000=y will not be handled correctly there?
I'd say yes, you are correct.
> And the best solution is to nuke all #ifdef's in this function and make
> the code unconditionally available?
---
~Randy
^ 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