From 97553f7f3e7a0305d017df9cc6e9589f64878437 Mon Sep 17 00:00:00 2001 From: Manfred Rudigier Date: Fri, 11 Jun 2010 01:49:05 +0000 Subject: gianfar: Fix setup of RX time stamping Previously the RCTRL_TS_ENABLE bit was set unconditionally. However, if the RCTRL_TS_ENABLE is set without TMR_CTRL[TE], the driver does not work properly on some boards (Anton had problems with the MPC8313ERDB and MPC8568EMDS). With this patch the bit will only be set if requested from user space with the SIOCSHWTSTAMP ioctl command, meaning that time stamping is disabled during normal operation. Users who are not interested in time stamps will not experience problems with buggy CPU revisions or performance drops any more. The setting of TMR_CTRL[TE] is still up to the user. This is considered safe because users wanting HW timestamps must initialize the eTSEC clock first anyway, e.g. with the recently submitted PTP clock driver. Signed-off-by: Manfred Rudigier Reviewed-by: Anton Vorontsov Signed-off-by: David S. Miller --- drivers/net/gianfar.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) (limited to 'drivers/net/gianfar.c') diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index 46c69cd..227b628 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ -381,10 +381,14 @@ static void gfar_init_mac(struct net_device *ndev) /* Insert receive time stamps into padding alignment bytes */ if (priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER) { rctrl &= ~RCTRL_PAL_MASK; - rctrl |= RCTRL_PRSDEP_INIT | RCTRL_TS_ENABLE | RCTRL_PADDING(8); + rctrl |= RCTRL_PADDING(8); priv->padding = 8; } + /* Enable HW time stamping if requested from user space */ + if (priv->hwts_rx_en) + rctrl |= RCTRL_PRSDEP_INIT | RCTRL_TS_ENABLE; + /* keep vlan related bits if it's enabled */ if (priv->vlgrp) { rctrl |= RCTRL_VLEX | RCTRL_PRSDEP_INIT; @@ -747,7 +751,8 @@ static int gfar_of_init(struct of_device *ofdev, struct net_device **pdev) FSL_GIANFAR_DEV_HAS_CSUM | FSL_GIANFAR_DEV_HAS_VLAN | FSL_GIANFAR_DEV_HAS_MAGIC_PACKET | - FSL_GIANFAR_DEV_HAS_EXTENDED_HASH; + FSL_GIANFAR_DEV_HAS_EXTENDED_HASH | + FSL_GIANFAR_DEV_HAS_TIMER; ctype = of_get_property(np, "phy-connection-type", NULL); @@ -805,12 +810,20 @@ static int gfar_hwtstamp_ioctl(struct net_device *netdev, switch (config.rx_filter) { case HWTSTAMP_FILTER_NONE: - priv->hwts_rx_en = 0; + if (priv->hwts_rx_en) { + stop_gfar(netdev); + priv->hwts_rx_en = 0; + startup_gfar(netdev); + } break; default: if (!(priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER)) return -ERANGE; - priv->hwts_rx_en = 1; + if (!priv->hwts_rx_en) { + stop_gfar(netdev); + priv->hwts_rx_en = 1; + startup_gfar(netdev); + } config.rx_filter = HWTSTAMP_FILTER_ALL; break; } -- cgit v1.1 From 63b88b9041ceef8217f34de71a2e96f0c3f0fd3b Mon Sep 17 00:00:00 2001 From: Anton Vorontsov Date: Fri, 11 Jun 2010 10:51:03 +0000 Subject: gianfar: Fix oversized packets handling Issuing the following command on host: $ ifconfig eth2 mtu 1600 ; ping 10.0.0.27 -s 1485 -c 1 Makes some boards (tested with MPC8315 rev 1.1 and MPC8313 rev 1.0) oops like this: skb_over_panic: text:c0195914 len:1537 put:1537 head:c79e4800 data:c79e4880 tail:0xc79e4e81 end:0xc79e4e80 dev:eth1 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:127! Oops: Exception in kernel mode, sig: 5 [#1] MPC831x RDB last sysfs file: /sys/kernel/uevent_seqnum Modules linked in: NIP: c01c1840 LR: c01c1840 CTR: c016d918 [...] NIP [c01c1840] skb_over_panic+0x48/0x5c LR [c01c1840] skb_over_panic+0x48/0x5c Call Trace: [c0339d50] [c01c1840] skb_over_panic+0x48/0x5c (unreliable) [c0339d60] [c01c3020] skb_put+0x5c/0x60 [c0339d70] [c0195914] gfar_clean_rx_ring+0x25c/0x3d0 [c0339dc0] [c01976e8] gfar_poll+0x170/0x1bc Dumped buffer descriptors showed that eTSEC's length/truncation logic sometimes passes oversized packets, i.e. for the above ICMP packet the following two buffer descriptors may become ready: status=1400 length=1536 status=1800 length=1541 So, it seems that gianfar actually receives the whole big frame, and it tries to place the packet into two BDs. This situation confuses the driver, and so the skb_put() sanity check fails. This patch fixes the issue by adding an appropriate check, i.e. the driver should not try to process frames with buffer descriptor's length over rx_buffer_size (i.e. maxfrm and mrblr). Note that sometimes eTSEC works correctly, i.e. in the second (last) buffer descriptor bits 'truncated' and 'crcerr' are set, and so there's no oops. Though I couldn't find any logic when it works correctly and when not. Signed-off-by: Anton Vorontsov Signed-off-by: David S. Miller --- drivers/net/gianfar.c | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'drivers/net/gianfar.c') diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index 227b628..28b53d1 100644 --- a/drivers/net/gianfar.c +++ b/drivers/net/gianfar.c @@ -2655,6 +2655,10 @@ int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue, int rx_work_limit) dma_unmap_single(&priv->ofdev->dev, bdp->bufPtr, priv->rx_buffer_size, DMA_FROM_DEVICE); + if (unlikely(!(bdp->status & RXBD_ERR) && + bdp->length > priv->rx_buffer_size)) + bdp->status = RXBD_LARGE; + /* We drop the frame if we failed to allocate a new buffer */ if (unlikely(!newskb || !(bdp->status & RXBD_LAST) || bdp->status & RXBD_ERR)) { -- cgit v1.1