- 08 Jan, 2010 3 commits
-
-
Sriram authored
In the driver probe function the emac module clock needs to be enabled before calling register_netdev(). As soon as the device is registered the driver get_stats function can be invoked by the core - the module clock must be switched on to be able to read from stats registers. Also explicitly call matching clk_disable for failure conditions in probe function. Signed-off-by:
Sriramakrishnan <srk@ti.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ben Hutchings authored
The Davicom DM9100 and DM9102 chips are used on the motherboards of some SPARC systems (supported by the tulip driver) and also in PCI expansion cards (supported by the dmfe driver). There is no difference in the PCI device ids for the two different configurations, so these drivers both claim the device ids. However, it is possible to distinguish the two configurations by the presence of Open Firmware properties for them, so we do that. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Grant Grundler <grundler@parisc-linux.org> Signed-off-by:
-
PJ Waskiewicz authored
tc is still throwing a warning that is could be used uninitialized. This fixes it, and properly formats the device ID checks for the use of this variable. Signed-off-by:
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
- 07 Jan, 2010 14 commits
-
-
Saeed Bishara authored
If NET_SKB_PAD is not a multiple of the cache line size, mv643xx_eth allocates a couple of extra bytes at the start of each receive buffer to make the data payload end up on a cache line boundary. These extra bytes are skb_reserve()'d before DMA mapping, so they should not be included in the DMA map byte count (as the mapping is done starting at skb->data), nor should they be included in the receive descriptor buffer size field, or the hardware can end up DMAing beyond the end of the buffer, which can happen if someone sends us a larger-than-MTU sized packet. This problem was introduced in commit 7fd96ce4 ("mv643xx_eth: rework receive skb cache alignment", May 6 2009), but hasn't appeared to be problematic so far, probably as the main users of mv643xx_eth all have NET_SKB_PAD == L1_CACHE_BYTES. Signed-off-by:
Saeed Bishara <saeed@marvell.com> Signed-off-by:
Lennert Buytenhek <buytenh@marvell.com> Signed-off-by:
-
Jiri Slaby authored
Stanse found a memory leak in atl2_get_eeprom. eeprom_buff is not freed/assigned on all paths. Fix that. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Jay Cliburn <jcliburn@gmail.com> Cc: Chris Snook <chris.snook@gmail.com> Cc: Jie Yang <jie.yang@atheros.com> Cc: atl1-devel@lists.sourceforge.net Cc: "David S. Miller" <davem@davemloft.net> Cc: netdev@vger.kernel.org Signed-off-by:
-
Alexander Beregalov authored
Signed-off-by:
Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by:
-
Mark Brown authored
A failure on request_irq() is always fatal but unlike other fatal errors it's only reported to the user if net_debug is set. Make the diagnostic unconditional and raise the priority so that errors are more obvious to the user. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Jan Dumon authored
Fixed missing newlines in calls to dev_warn & dev_err. Signed-off-by:
Jan Dumon <j.dumon@option.com> Signed-off-by:
-
Jan Dumon authored
Don't send flow control settings to any port other than the modem port. Older firmware ignored this request but did sent a reply. Newer firmware just ignores it without reply and causes a 5 second timeout every time a port (except for the modem port) is opened or if tiocm settings are changed. Signed-off-by:
-
Jan Dumon authored
Attempt to reset the usb device when we receive usb bus errors. Signed-off-by:
-
Jan Dumon authored
Don't change the state of a port if it's not open. This fixes an issue where a port sometimes has to be opened twice before data can be received. Signed-off-by:
-
Jan Dumon authored
Some fields are always little endian and have to be converted on big endian machines. Signed-off-by:
-
Jan Dumon authored
Add product ID's for new devices. Signed-off-by:
-
Ursula Braun authored
Claw module cannot be loaded together with qeth, because "qeth" has been errorneously used as root device name. It is changed into "claw". Signed-off-by:
Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by:
-
Ken Kawasaki authored
pcnet_cs,serial_cs: add cis of KTI PE520 pcmcia network card, and serial card(Sierra Wireless AC860). Signed-off-by:
Ken Kawasaki <ken_kawasaki@spring.nifty.jp> Signed-off-by:
-
Octavian Purdila authored
When we have L3 tunnels with different inner/outer families (i.e. IPV4/IPV6) which use a multicast address as the outer tunnel destination address, multicast packets will be loopbacked back to the sending socket even if IP*_MULTICAST_LOOP is set to disabled. The mc_loop flag is present in the family specific part of the socket (e.g. the IPv4 or IPv4 specific part). setsockopt sets the inner family mc_loop flag. When the packet is pushed through the L3 tunnel it will eventually be processed by the outer family which if different will check the flag in a different part of the socket then it was set. Signed-off-by:
Octavian Purdila <opurdila@ixiacom.com> Signed-off-by:
-
Dave Liu authored
current the Rx/Tx FIFO size settings cause problem when four UEC ethernets work simultaneously. eg: GETH1, UEM-J15, GETH2, UEC-J5 on 8569MDS board $ ifconfig eth0 10.193.20.166 $ ifconfig eth1 10.193.20.167 $ ifconfig eth2 10.193.20.168 then $ ifconfig eth3 10.193.20.169 The fourth ethernet will cause all of interface broken, you cann't ping successfully any more. The patch fix this issue for MPC8569 Rev1.0 and Rev2.0 Signed-off-by:
Dave Liu <daveliu@freescale.com> Acked-by:
Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by:
-
- 04 Jan, 2010 17 commits
-
-
David S. Miller authored
As noticed by Stephen Rothwell. Signed-off-by: -
Sucheta Chakraborty authored
o Fix ethtool link test for NX3031 chip. o Remove unused code from phy interrupt callback Signed-off-by:
Sucheta Chakraborty <sucheta.chakraborty@qlogic.com> Signed-off-by:
Amit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by:
-
Sucheta Chakraborty authored
o Dump registers such as tx ring and rx ring counter, firmware state, niu regs, etc. which can be useful for debugging purpose. Signed-off-by:
-
Dan Carpenter authored
tx_skbuff is define as: struct sk_buff *tx_skbuff[TX_RING_ENTRIES]; EVT_RING_ENTRIES is 64 and TX_RING_ENTRIES is 32. This function is in a error path so that's why it wasn't noticed. Signed-off-by:Dan Carpenter <error27@gmail.com> Signed-off-by:
-
roel kluin authored
This always evaluates to true. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Signed-off-by:
-
roel kluin authored
If no break occurred, cnt reaches 0 after the loop. Signed-off-by:
-
roel kluin authored
With `while (--limit > 0)' i reaches 0 after the loop, so upon timeout the error was not returned. Signed-off-by:
-
roel kluin authored
With `while (--i > 0)' i reaches 0 after the loop, so upon timeout the error was not issued. Signed-off-by:
-
Julia Lawall authored
lp->rx_skb has type struct sk_buff **, not struct sk_buff *, so the elements of the array should have pointer type, not structure type. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @disable sizeof_type_expr@ type T; T **x; @@ x = <+...sizeof( - T + *x )...+> // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
-
Rakesh Ranjan authored
Fix a target login issue, when parent interface is vlan and we are using cxgb3i sepecific private ip address in '/etc/iscsi/ifaces/' iface file. Acked-by:
Karen Xie <kxie@chelsio.com> Signed-off-by:
Rakesh Ranjan <rakesh@chelsio.com> Signed-off-by:
-
Dan Carpenter authored
This should address the problems in version 1 (lazy) and version 2 (ugly). Bump the stats on orig_dev not on the newly assigned NULL dev variable. Signed-off-by:
-
roel kluin authored
With `while (i++ < MII_TIMEOUT)' i reaches MII_TIMEOUT + 1 after the loop This is probably unlikely a problem in practice. Signed-off-by:
-
Julia Lawall authored
Test the just-allocated value for NULL rather than some other value. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x,y; statement S; @@ x = \(kmalloc\|kcalloc\|kzalloc\)(...); ( if ((x) == NULL) S | if ( - y + x == NULL) S ) // </smpl> Signed-off-by:
Oliver Hartkopp <oliver@hartkopp.net> Signed-off-by:
-
Julia Lawall authored
The code checked slot_rx twice. Check slot_tx by analogy with the bank case. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression E; @@ ( *E && E | *E || E ) // </smpl> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Andrew Morton authored
net/sctp/socket.c: In function 'sctp_setsockopt_autoclose': net/sctp/socket.c:2090: warning: comparison is always false due to limited range of data type Cc: Andrei Pelinescu-Onciul <andrei@iptel.org> Cc: Vlad Yasevich <vladislav.yasevich@hp.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
Bernard Pidoux F6BVP authored
cat /proc/net/rose displayed a rose sockets abnormal lci value, i.e. greater than maximum number of VCs per neighbour allowed. This number prevents further test of lci value during rose operations. Example (lines shortened) : [bernard]# cat /proc/net/rose dest_addr dest_call src_addr src_call dev lci neigh st vs vr va * * 2080175520 F6BVP-1 rose0 000 00000 0 0 0 0 2080175520 FPAD-0 2080175520 WP-0 rose0 FFE 00001 3 0 0 0 Here are the default parameters : linux/include/net/rose.h:#define ROSE_DEFAULT_MAXVC 50 /* Maximum number of VCs per neighbour */ linux/net/rose/af_rose.c:int sysctl_rose_maximum_vcs = ROSE_DEFAULT_MAXVC; With the following patch, rose_loopback_timer() attributes a VC number within limits. Signed-off-by:
Bernard Pidoux <f6bvp@amsat.org> Signed-off-by:
-
Ben Hutchings authored
velocity_open() calls velocity_give_many_rx_descs(), which gives RX descriptors to the NIC, before installing an interrupt handler or calling velocity_init_registers(). I think this is very unsafe and it appears to explain the bug report <http://bugs.debian.org/508527>. On MTU change, velocity_give_many_rx_descs() is again called before velocity_init_registers(). I'm not sure whether this is unsafe but it does look wrong. Therefore, move the calls to velocity_give_many_rx_descs() after request_irq() and velocity_init_registers(). Signed-off-by:
Jan Ceuleers <jan.ceuleers@computer.org> Signed-off-by:
-
- 31 Dec, 2009 4 commits
-
-
Anton Vorontsov authored
We use a rather complicated logic to support eTSEC and eTSEC2.0 registers maps in a single driver. Currently, the code tries to unmap 'regs', but for non-eTSEC2.0 controllers 'regs' doesn't point to a mapping start, and this might cause badness on probe failure or module removal: Freescale PowerQUICC MII Bus: probed Trying to vfree() nonexistent vm area (e107f000) ------------[ cut here ]------------ Badness at c00a7754 [verbose debug info unavailable] NIP: c00a7754 LR: c00a7754 CTR: c02231ec [...] NIP [c00a7754] __vunmap+0xec/0xf4 LR [c00a7754] __vunmap+0xec/0xf4 Call Trace: [df827e50] [c00a7754] __vunmap+0xec/0xf4 (unreliable) [df827e70] [c001519c] iounmap+0x44/0x54 [df827e80] [c028b924] fsl_pq_mdio_probe+0x1cc/0x2fc [df827eb0] [c02fb9b4] of_platform_device_probe+0x5c/0x84 [df827ed0] [c0229928] really_probe+0x78/0x1a8 [df827ef0] [c0229b20] __driver_attach+0xa4/0xa8 Fix this by introducing a proper priv structure (finally!), which now holds 'regs' and 'map' fields separately. Signed-off-by:
-
Anton Vorontsov authored
Sometimes ucc_geth fails to suspend with the following trace: ucc_geth e0103000.ucc: suspend ucc_geth e0102000.ucc: suspend NETDEV WATCHDOG: eth0 (ucc_geth): transmit queue 0 timed out ------------[ cut here ]------------ Badness at net/sched/sch_generic.c:255 NIP: c021cb5c LR: c021cb5c CTR: c01ab4b4 [...] NIP [c021cb5c] dev_watchdog+0x298/0x2a8 LR [c021cb5c] dev_watchdog+0x298/0x2a8 Call Trace: [c0389da0] [c021cb5c] dev_watchdog+0x298/0x2a8 (unreliable) [c0389e00] [c0031ed8] run_timer_softirq+0x16c/0x1dc [c0389e50] [c002c638] __do_softirq+0xa4/0x11c [...] This patch fixes the issue by properly detaching the device on suspend, and attaching it back on resume. Signed-off-by:
-
Anton Vorontsov authored
Since hibernation assumes power loss, we should fully reinitialize PHYs (including platform fixups), as if PHYs were just attached. This patch factors phy_init_hw() out of phy_attach_direct(), then converts mdio_bus to dev_pm_ops and adds an appropriate restore() callback. Signed-off-by:
-
Anton Vorontsov authored
Sometimes kernel hangs on resume with the following trace: ucc_geth e0102000.ucc: resume INFO: task bash:1764 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. bash D 0fecf43c 0 1764 1763 0x00000000 Call Trace: [cf9a7c10] [c0012868] ret_from_except+0x0/0x14 (unreliable) --- Exception: cf9a7ce0 at __switch_to+0x4c/0x6c LR = 0xcf9a7cc0 [cf9a7cd0] [c0008c14] __switch_to+0x4c/0x6c (unreliable) [cf9a7ce0] [c028bcfc] schedule+0x158/0x260 [cf9a7d10] [c028c720] __mutex_lock_slowpath+0x80/0xd8 [cf9a7d40] [c01cf388] phy_stop+0x20/0x70 [cf9a7d50] [c01d514c] ugeth_resume+0x6c/0x13c [...] Here is why. On suspend: - PM core starts suspending devices, ucc_geth_suspend gets called; - ucc_geth calls phy_stop() on suspend. Note that phy_stop() is mostly asynchronous so it doesn't block ucc_geth's suspend routine, it just sets PHY_HALTED state and disables PHY's interrupts; - Suddenly the state machine gets scheduled, it grabs the phydev->lock mutex and tries to process the PHY_HALTED state, so it calls phydev->adjust_link(phydev->attached_dev). In ucc_geth case adjust_link() calls msleep(), which reschedules the code flow back to PM core, which now finishes suspend and so we end up sleeping with phydev->lock mutex held. On resume: - PM core starts resuming devices (notice that nobody rescheduled the state machine yet, so the mutex is still held), the core calls ucc_geth's resume routine; - ucc_geth_resume restarts the PHY with phy_stop()/phy_start() sequence, and the phy_*() calls are trying to grab the phydev->lock mutex. Here comes the deadlock. This patch fixes the issue by stopping the state machine on suspend and starting it again on resume. Signed-off-by:
-
- 30 Dec, 2009 1 commit
-
-
- 29 Dec, 2009 1 commit
-
-
John W. Linville authored
This reverts commit 9bd568a5. That commit is shown to cause allocation failures during initialization on some machines. http://bugzilla.kernel.org/show_bug.cgi?id=14844Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
