kernel/linux.git/drivers/net/wan, branch v2.6.32

wan: cosa: drop chan->wsem on error path

2009-11-30T08:06:51+00:00

The other paths all drop chan->wsem. This was found by a static checker (smatch). Signed-off-by: Dan Carpenter Acked-by: Jan "Yenya" Kasprzak Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6

2009-10-15T22:03:17+00:00

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (53 commits) vmxnet: fix 2 build problems net: add support for STMicroelectronics Ethernet controllers. net: ks8851_mll uses mii interfaces net/fec_mpc52xx: Fix kernel panic on FEC error net: Fix OF platform drivers coldplug/hotplug when compiled as modules TI DaVinci EMAC: Clear statistics register properly. r8169: partial support and phy init for the 8168d irda/sa1100_ir: check return value of startup hook udp: Fix udp_poll() and ioctl() WAN: fix Cisco HDLC handshaking. tcp: fix tcp_defer_accept to consider the timeout 3c574_cs: spin_lock the set_multicast_list function net: Teach pegasus driver to ignore bluetoother adapters with clashing Vendor:Product IDs netxen: fix pci bar mapping ethoc: fix warning from 32bit build libertas: fix build net: VMware virtual Ethernet NIC driver: vmxnet3 net: Fix IXP 2000 network driver building. libertas: fix build mac80211: document ieee80211_rx() context requirement ...

headers: Fix build after removal

2009-10-13T17:20:16+00:00

Commit d43c36dc6b357fa1806800f18aa30123c747a6d1 ("headers: remove sched.h from interrupt.h") left some build errors in some configurations due to drivers having depended on getting header files "accidentally". Signed-off-by: Ingo Molnar [ Combined several one-liners from Ingo into one single patch - Linus ] Signed-off-by: Linus Torvalds

WAN: fix Cisco HDLC handshaking.

2009-10-13T10:16:53+00:00

Cisco HDLC uses keepalive packets and sequence numbers to determine link state. In rare cases both ends could transmit keepalive packets at the same time, causing the received sequence numbers to be treated as incorrect. Now we accept our current sequence number as well as the previous one. Signed-off-by: Krzysztof Hałasa Signed-off-by: David S. Miller

headers: remove sched.h from interrupt.h

2009-10-11T18:20:58+00:00

After m68k's task_thread_info() doesn't refer to current, it's possible to remove sched.h from interrupt.h and not break m68k! Many thanks to Heiko Carstens for allowing this. Signed-off-by: Alexey Dobriyan

drivers/net/wan: introduce missing kfree

2009-09-11T19:54:30+00:00

Error handling code following a kmalloc should free the allocated data. The semantic match that finds the problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // @r exists@ local idexpression x; statement S; expression E; identifier f,f1,l; position p1,p2; expression *ptr != NULL; @@ x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...); ... if (x == NULL) S <... when != x when != if (...) { <+...x...+> } ( x->f1 = E | (x->f1 == NULL || ...) | f(...,x->f1,...) ) ...> ( return \(0\|<+...x...+>\|ptr\); | return@p2 ...; ) @script:python@ p1 << r.p1; p2 << r.p2; @@ print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line) // Signed-off-by: Julia Lawall Signed-off-by: David S. Miller

IXP42x HSS support for setting internal clock rate

2009-09-07T08:56:49+00:00

HSS usually uses external clocks, so it's not a big deal. Internal clock is used for direct DTE-DTE connections and when the DCE doesn't provide it's own clock. This also depends on the oscillator frequency. Intel seems to have calculated the clock register settings for 33.33 MHz (66.66 MHz timer base). Their settings seem quite suboptimal both in terms of average frequency (60 ppm is unacceptable for G.703 applications, their primary intended usage(?)) and jitter. Many (most?) platforms use a 33.333 MHz oscillator, a 10 ppm difference from Intel's base. Instead of creating static tables, I've created a procedure to program the HSS clock register. The register consists of 3 parts (A, B, C). The average frequency (= bit rate) is: 66.66x MHz / (A + (B + 1) / (C + 1)) The procedure aims at the closest average frequency, possibly at the cost of increased jitter. Nobody would be able to directly drive an unbufferred transmitter with a HSS anyway, and the frequency error is what it really counts. I've verified the above with an oscilloscope on IXP425. It seems IXP46x and possibly IXP43x use a bit different clock generation algorithm - it looks like the avg frequency is: (on IXP465) 66.66x MHz / (A + B / (C + 1)). Also they use much greater precomputed A and B - on IXP425 it would simply result in more jitter, but I don't know how does it work on IXP46x (perhaps 3 least significant bits aren't used?). Anyway it looks that they were aiming for exactly +60 ppm or -60 ppm, while <1 ppm is typically possible (with a synchronized clock, of course). The attached patch makes it possible to set almost any bit rate (my IXP425 533 MHz quits at > 22 Mb/s if a single port is used, and the minimum is ca. 65 Kb/s). This is independent of MVIP (multi-E1/T1 on one HSS) mode. Signed-off-by: Krzysztof Hałasa Signed-off-by: David S. Miller

WAN: remove deprecated PCI_DEVICE_ID from PCI200SYN driver.

2009-09-07T08:56:45+00:00

PCI200SYN has its own PCI subsystem device ID for 3+ years, now it's time to remove the generic PLX905[02] ID from the driver. Anyone with old EEPROM data will have to run the upgrade. Having the generic PLX905[02] (PCI-local bus bridge) ID is harmful as the driver tries to handle other devices based on these bridges. Signed-off-by: Krzysztof Halasa Signed-off-by: David S. Miller

wan: dlci/sdla transmit return dehacking

2009-09-07T08:56:33+00:00

This is a brute force removal of the wierd slave interface done for DLCI -> SDLA transmit. Before it was using non-standard return values and freeing skb in caller. This changes it to using normal return values, and freeing in the callee. Luckly only one driver pair was doing this. Not tested on real hardware, in fact I wonder if this driver pair is even being used by any users. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller

WAN: dscc4: Fix warning pointing out a bug.

2009-09-04T04:34:39+00:00

Noticed by Stephen Rothwell: Today's linux-next build (x86_64 allmodconfig gcc-4.4.0) produced this warning: drivers/net/wan/dscc4.c: In function 'dscc4_rx_skb': drivers/net/wan/dscc4.c:670: warning: suggest parentheses around comparison in operand of '|' which actually points out a bug, I think. It is doing (x & (y | z)) != y | z when it probably means (x & (y | z)) != (y | z) Introduced by commit 5de3fcab91b0e1809eec030355d15801daf25083 ("WAN: bit and/or confusion"). Signed-off-by: David S. Miller