For carrier detection to work properly when binding the driver with a cable
unplugged, netif_carrier_off() should be called after register_netdev(),
not before.
Signed-off-by: NPaul Fertser <fercerpav@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Stanse found that i2400m_rx frees skb, but still uses skb->len even
though it has skb_len defined. So use skb_len properly in the code.

And also define it unsinged int rather than size_t to solve
compilation warnings.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Cc: linux-wimax@intel.com
Acked-by: NInaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

with hardware slow in negotiation, the system did freeze
while trying to mount root on nfs at boot time.

the link state has not been initialised so network stack
tried to start transmission right away. this caused instant
retries, as the driver solely stated business upon link down,
rendering the system unusable.

notify carrier off initially to prevent transmission until
phylib will report link up.
Signed-off-by: NOskar Schirmer <oskar@linutronix.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use DMA API as PCI equivalents will be deprecated. This change also
allow to allocate with GFP_KERNEL where possible.
Tested-by: NNeal Becker <ndbecker2@gmail.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We have fedora bug report where driver fail to initialize after
suspend/resume because of memory allocation errors:
https://bugzilla.redhat.com/show_bug.cgi?id=629158

To fix use GFP_KERNEL allocation where possible.
Tested-by: NNeal Becker <ndbecker2@gmail.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

  wireless-testing
  commit 37e5bf65
  Author: Luis R. Rodriguez <lrodriguez@atheros.com>
  Date:   Sat Jun 12 00:33:40 2010 -0400

    ath9k_hw: fix clock rate calculations for ANI

This commit accidentally broke clock rate calculation by doubling the
calculated clock rate
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix a WARN_ON failure in bond_masters sysfs file

Got a report of this warning recently

bonding: bond0 is being created...
------------[ cut here ]------------
WARNING: at fs/proc/generic.c:590 proc_register+0x14d/0x185()
Hardware name: ProLiant BL465c G1
proc_dir_entry 'bonding/bond0' already registered
Modules linked in: bonding ipv6 tg3 bnx2 shpchp amd64_edac_mod edac_core
ipmi_si
ipmi_msghandler serio_raw i2c_piix4 k8temp edac_mce_amd hpwdt microcode hpsa
cc
iss radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded:
scsi_wai
t_scan]
Pid: 935, comm: ifup-eth Not tainted 2.6.33.5-124.fc13.x86_64 #1
Call Trace:
[<ffffffff8104b54c>] warn_slowpath_common+0x77/0x8f
[<ffffffff8104b5b1>] warn_slowpath_fmt+0x3c/0x3e
[<ffffffff8114bf0b>] proc_register+0x14d/0x185
[<ffffffff8114c20c>] proc_create_data+0x87/0xa1
[<ffffffffa0211e9b>] bond_create_proc_entry+0x55/0x95 [bonding]
[<ffffffffa0215e5d>] bond_init+0x95/0xd0 [bonding]
[<ffffffff8138cd97>] register_netdevice+0xdd/0x29e
[<ffffffffa021240b>] bond_create+0x8e/0xb8 [bonding]
[<ffffffffa021c4be>] bonding_store_bonds+0xb3/0x1c1 [bonding]
[<ffffffff812aec85>] class_attr_store+0x27/0x29
[<ffffffff8115423d>] sysfs_write_file+0x10f/0x14b
[<ffffffff81101acf>] vfs_write+0xa9/0x106
[<ffffffff81101be2>] sys_write+0x45/0x69
[<ffffffff81009b02>] system_call_fastpath+0x16/0x1b
---[ end trace a677c3f7f8b16b1e ]---
bonding: Bond creation failed.

It happens because a user space writer to bond_master can try to
register an already existing bond interface name.  Fix it by teaching
bond_create to check for the existance of devices with that name first
in cases where a non-NULL name parameter has been passed in
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Skge devices installed on some Gigabyte motherboards are not able to
perform 64 dma correctly due to board PCI implementation, so limit
DMA to 32bit if such boards are detected.

Bug was reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=447489Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Tested-by: NLuya Tshimbalanga <luya@fedoraproject.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since 'select' ignores dependencies, drivers that select INET_LRO must
depend on INET.  This fixes the broken configuration reported in
<http://article.gmane.org/gmane.linux.kernel/825646>.
Reported-by: NSubrata Modak <subrata@linux.vnet.ibm.com>
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

iwl3945's scan_completed calls into the mac80211 stack which triggers a
warn on if there is no scan outstanding.

This can be avoided by not calling scan_completed but abort_scan in
iwl3945_request_scan  in the done: branch of the function which is used
as an error out.

The done: branch seems to be an error-out branch, as, for example, if
iwl_is_ready(priv) returns false  the done: branch is executed.

NOTE:
I'm not familiar with the driver at all.
I just quickly scanned as a reaction to

https://bugzilla.kernel.org/show_bug.cgi?id=17722

the users of scan_completed in the  iwl3945 driver and noted the odd
discrepancy between the comment above this instance and the comment in
mac80211 scan_completed function.
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the interface is up, using ethtool breaks it because:
a) link is put down but media_timer interval is not shortened to NO_LINK
b) rxtx is stopped but not restarted

Also manual 10baseT-HD (and probably FD too - untested) mode does not work -
the link is forced up, packets are transmitted but nothing is received.
Changing CSR14 value to match documentation (not disabling link check) fixes this.
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Acked-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch (commit 690a1f20) added a
new call site for acpi_set_WOL() without checking that the function is
actually suitable to be called via

 vortex_set_wol+0xcd/0xe0 [3c59x]
 dev_ethtool+0xa5a/0xb70
 dev_ioctl+0x2e0/0x4b0
 T.961+0x49/0x50
 sock_ioctl+0x47/0x290
 do_vfs_ioctl+0x7f/0x340
 sys_ioctl+0x80/0xa0
 system_call_fastpath+0x16/0x1b

i.e. outside of code paths run when the device is not yet enabled or
already disabled. In particular, putting the device into D3hot is a
pretty bad idea when it was already brought up.

Furthermore, all prior callers of the function made sure they're
actually dealing with a PCI device, while the newly added one didn't.

In the same spirit, the .get_wol handler shouldn't indicate support
for WOL for non-PCI devices.
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Freeing netdev without free_netdev() leads to net, tx leaks.
I might lead to dereferencing freed pointer.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

@@
struct net_device* dev;
@@

-kfree(dev)
+free_netdev(dev)
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Freeing netdev without free_netdev() leads to net, tx leaks.
I might lead to dereferencing freed pointer.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

@@
struct net_device* dev;
@@

-kfree(dev)
+free_netdev(dev)
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Freeing netdev without free_netdev() leads to net, tx leaks.
I might lead to dereferencing freed pointer.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

@@
struct net_device* dev;
@@

-kfree(dev)
+free_netdev(dev)
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This enables auto loading for the smsc911x ethernet driver.
Signed-off-by: NVincent Stehlé <vincent.stehle@laposte.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Compex FreedomLine 32 PnP-PCI2 cards have only TP and BNC connectors but the
SROM contains AUI port too. When TP loses link, the driver switches to
non-existing AUI port (which reports that carrier is always present).

Connecting TP back generates LinkPass interrupt but de_media_interrupt() is
broken - it only updates the link state of currently connected media, ignoring
the fact that LinkPass and LinkFail bits of MacStatus register belong to the
TP port only (the chip documentation says that).

This patch changes de_media_interrupt() to switch media to TP when link goes
up (and media type is not locked) and also to update the link state only when
the TP port is used.

Also the NonselPortActive (and also SelPortActive) bits of SIAStatus register
need to be cleared (by writing 1) after reading or they're useless.
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Acked-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

At least my 21041 cards come out of suspend with bus mastering disabled so
they did not work after resume(no data transferred).
After adding pci_set_master(), the driver oopsed immediately on resume -
because de_clean_rings() is called on suspend but de_init_rings() call
was missing in resume.

Also disable link (reset SIA) before sleep (de4x5 does this too).
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Acked-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

At least on older 21041-AA chips (mine is rev. 11), TP duplex autonegotiation
causes the card not to work at all (link is up but no packets are transmitted).

de4x5 disables autonegotiation completely. But it seems to work on newer
(21041-PA rev. 21) so disable it only on rev<20 chips.
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Acked-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For non-managed versions of 82579, set the bit that prevents the hardware
from automatically configuring the PHY after resets only when the driver
performs a reset, clear the bit after resets.  This is so the hardware can
configure the PHY automatically when the part is reset in a manner that is
not controlled by the driver (e.g. in a virtual environment via PCI FLR)
otherwise the PHY will be mis-configured causing issues such as failing to
link at 1000Mbps.
For managed versions of 82579, keep the previous behavior since the
manageability firmware will handle the PHY configuration.
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The subject workaround was causing CRC errors due to writing the wrong
register with updates of the RCTL register.  It was also found that the
workaround function which modifies the RCTL register was being called in
the middle of a read-modify-write operation of the RCTL register, so the
function call has been moved appropriately.  Lastly, jumbo frames must not
be allowed when CRC stripping is disabled by a module parameter because the
workaround requires the CRC be stripped.
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On 82579, there is a hardware bug that can cause received packets to not
get transferred from the PHY to the MAC due to K1 (a power saving feature
of the PHY-MAC interconnect similar to ASPM L1).  Since the MAC controls
the accounting of missed packets, these will go unnoticed.  Workaround the
issue by setting the K1 beacon duration according to the link speed.
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Two recent patches to cleanup the reset[1] and initial PHY configuration[2]
code paths for ICH/PCH devices inadvertently left out a 10msec delay and
device ID check respectively which are necessary for the 82566DC (device id
0x104b) to be configured properly, otherwise it will not get link.

[1] commit e98cac44
[2] commit 3f0c16e8

CC: stable@kernel.org
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since the hardware is prevented from performing automatic PHY configuration
(the driver does it instead), the OEM_WRITE_ENABLE bit in the EXTCNF_CTRL
register will not get cleared preventing the SMBus address and the LED
configuration to be written to the PHY registers.  On 82579, do not check
the OEM_WRITE_ENABLE bit.
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When going to Sx, disable gigabit in PHY (e1000_oem_bits_config_ich8lan)
in addition to the MAC before configuring PHY wakeup otherwise the PHY
configuration writes might be missed.  Also write the LED configuration
and SMBus address to the PHY registers (e1000_oem_bits_config_ich8lan and
e1000_write_smbus_addr, respectively).  The reset is no longer needed
since re-auto-negotiation is forced in e1000_oem_bits_config_ich8lan and
leaving it in causes issues with auto-negotiating the link.
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

They are allocated in atl1_setup_ring_resources, zero out the pointers
in atl1_free_ring_resources (like the other resources).
Signed-off-by: NLuca Tettamanti <kronos.it@gmail.com>
Acked-by: NChris Snook <chris.snook@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

adapter->cmb.cmb is initialized when the device is opened and freed when
it's closed. Accessing it unconditionally during resume results either
in a crash (NULL pointer dereference, when the interface has not been
opened yet) or data corruption (when the interface has been used and
brought down adapter->cmb.cmb points to a deallocated memory area).

Cc: stable@kernel.org
Signed-off-by: NLuca Tettamanti <kronos.it@gmail.com>
Acked-by: NChris Snook <chris.snook@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

skb->truesize is set in core network.

Dont change it unless dealing with fragments.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

skb->truesize is set in core network.

Dont change it unless dealing with fragments.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

qlcnic driver allocates rx skbs and gives to hardware too bytes of extra
storage, allowing for corruption of kernel data.

NET_IP_ALIGN being 0 on some platforms (including x86), drivers should
not assume it's 2.

rds_ring->skb_size = rds_ring->dma_size + NET_IP_ALIGN;
...
skb = dev_alloc_skb(rds_ring->skb_size);
skb_reserve(skb, 2);
pci_map_single(pdev, skb->data, rds_ring->dma_size, PCI_DMA_FROMDEVICE);

(and rds_ring->skb_size == rds_ring->dma_size) -> bug


Because of extra alignment (1500 + 32) -> four extra bytes are available
before the struct skb_shared_info, so corruption is not noticed.

Note: this driver could use netdev_alloc_skb_ip_align()
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When uCode error condition detected, driver try to perform either
rf reset or firmware reload in order bring device back to
working condition.

If rf reset is required and scan is in process, there is no need
to issue rf reset since scan already reset the rf.

If firmware reload is required and scan is in process, skip the
reload request. There is a possibility firmware reload during
scan cause problem.

[  485.804046] WARNING: at net/mac80211/main.c:310 ieee80211_restart_hw+0x28/0x62()
[  485.804049] Hardware name: Latitude E6400
[  485.804052] ieee80211_restart_hw called with hardware scan in progress
[  485.804054] Modules linked in: iwlagn iwlcore bnep sco rfcomm l2cap crc16 bluetooth [last unloaded: iwlcore]
[  485.804069] Pid: 812, comm: kworker/u:3 Tainted: G        W   2.6.36-rc3-wl+ #74
[  485.804072] Call Trace:
[  485.804079]  [<c103019a>] warn_slowpath_common+0x60/0x75
[  485.804084]  [<c1030213>] warn_slowpath_fmt+0x26/0x2a
[  485.804089]  [<c145da67>] ieee80211_restart_hw+0x28/0x62
[  485.804102]  [<f8b35dc6>] iwl_bg_restart+0x113/0x150 [iwlagn]
[  485.804108]  [<c10415d5>] process_one_work+0x181/0x25c
[  485.804119]  [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn]
[  485.804124]  [<c104190a>] worker_thread+0xf9/0x1f2
[  485.804128]  [<c1041811>] ? worker_thread+0x0/0x1f2
[  485.804133]  [<c10451b0>] kthread+0x64/0x69
[  485.804137]  [<c104514c>] ? kthread+0x0/0x69
[  485.804141]  [<c1002df6>] kernel_thread_helper+0x6/0x10
[  485.804145] ---[ end trace 3d4ebdc02d524bbb ]---
[  485.804148] WG> 1
[  485.804153] Pid: 812, comm: kworker/u:3 Tainted: G        W   2.6.36-rc3-wl+ #74
[  485.804156] Call Trace:
[  485.804161]  [<c145da9b>] ? ieee80211_restart_hw+0x5c/0x62
[  485.804172]  [<f8b35dcb>] iwl_bg_restart+0x118/0x150 [iwlagn]
[  485.804177]  [<c10415d5>] process_one_work+0x181/0x25c
[  485.804188]  [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn]
[  485.804192]  [<c104190a>] worker_thread+0xf9/0x1f2
[  485.804197]  [<c1041811>] ? worker_thread+0x0/0x1f2
[  485.804201]  [<c10451b0>] kthread+0x64/0x69
[  485.804205]  [<c104514c>] ? kthread+0x0/0x69
[  485.804209]  [<c1002df6>] kernel_thread_helper+0x6/0x10
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Fixed formatting (tabs and line breaks).

The CHELSIO_GET_QSET_NUM device ioctl allows unprivileged users to read
4 bytes of uninitialized stack memory, because the "addr" member of the
ch_reg struct declared on the stack in cxgb_extension_ioctl() is not
altered or zeroed before being copied back to the user.  This patch
takes care of it.
Signed-off-by: NDan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fixed formatting (tabs and line breaks).

The EQL_GETMASTRCFG device ioctl allows unprivileged users to read 16
bytes of uninitialized stack memory, because the "master_name" member of
the master_config_t struct declared on the stack in eql_g_master_cfg()
is not altered or zeroed before being copied back to the user.  This
patch takes care of it.
Signed-off-by: NDan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fixed formatting (tabs and line breaks).

The TIOCGICOUNT device ioctl allows unprivileged users to read
uninitialized stack memory, because the "reserved" member of the
serial_icounter_struct struct declared on the stack in hso_get_count()
is not altered or zeroed before being copied back to the user.  This
patch takes care of it.
Signed-off-by: NDan Rosenberg <dan.j.rosenberg@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The Thinkpad X100e seems to have some odd behaviour when the display is
powered off - the onboard r8169 starts generating rxfifo overflow errors.
The root cause of this has not yet been identified and may well be a
hardware design bug on the platform, but r8169 should be more resiliant to
this. This patch enables the rxfifo interrupt on 8168 devices and removes
the MAC version check in the interrupt handler, and the machine no longer
crashes when under network load while the screen turns off.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There is no need to use spinlocks in vortex_{set|get}_wol.
This also fixes a bug:
[  254.214993] 3c59x 0000:00:0d.0: PME# enabled
[  254.215021] BUG: sleeping function called from invalid context at kernel/mutex.c:94
[  254.215030] in_atomic(): 0, irqs_disabled(): 1, pid: 4875, name: ethtool
[  254.215042] Pid: 4875, comm: ethtool Tainted: G        W   2.6.36-rc3+ #7
[  254.215049] Call Trace:
[  254.215050]  [] __might_sleep+0xb1/0xb6
[  254.215050]  [] mutex_lock+0x17/0x30
[  254.215050]  [] acpi_enable_wakeup_device_power+0x2b/0xb1
[  254.215050]  [] acpi_pm_device_sleep_wake+0x42/0x7f
[  254.215050]  [] acpi_pci_sleep_wake+0x5d/0x63
[  254.215050]  [] platform_pci_sleep_wake+0x1d/0x20
[  254.215050]  [] __pci_enable_wake+0x90/0xd0
[  254.215050]  [] acpi_set_WOL+0x8e/0xf5 [3c59x]
[  254.215050]  [] vortex_set_wol+0x4e/0x5e [3c59x]
[  254.215050]  [] dev_ethtool+0x1cf/0xb61
[  254.215050]  [] ? debug_mutex_free_waiter+0x45/0x4a
[  254.215050]  [] ? __mutex_lock_common+0x204/0x20e
[  254.215050]  [] ? __mutex_lock_slowpath+0x12/0x15
[  254.215050]  [] ? mutex_lock+0x23/0x30
[  254.215050]  [] dev_ioctl+0x42c/0x533
[  254.215050]  [] ? _cond_resched+0x8/0x1c
[  254.215050]  [] ? lock_page+0x1c/0x30
[  254.215050]  [] ? page_address+0x15/0x7c
[  254.215050]  [] ? filemap_fault+0x187/0x2c4
[  254.215050]  [] sock_ioctl+0x1d4/0x1e0
[  254.215050]  [] ? sock_ioctl+0x0/0x1e0
[  254.215050]  [] vfs_ioctl+0x19/0x33
[  254.215050]  [] do_vfs_ioctl+0x424/0x46f
[  254.215050]  [] ? selinux_file_ioctl+0x3c/0x40
[  254.215050]  [] sys_ioctl+0x40/0x5a
[  254.215050]  [] sysenter_do_call+0x12/0x22

vortex_set_wol protected with a spinlock, but nested  acpi_set_WOL acquires a mutex inside atomic context.
Ethtool operations are already serialized by RTNL mutex, so it is safe to drop the locks.
Signed-off-by: NDenis Kirjanov <dkirjanov@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Some pcnet_cs compatible cards require an exact 16-lines match
of the ioport areas specified in CIS, but set the "iolines"
value in the CIS incorrectly. We can easily work around this
issue -- same as we do in serial_cs -- by first trying setting
iolines to the CIS-specified value, and then trying a 16-line
match.
Reported-and-tested-by: NWolfram Sang <w.sang@pengutronix.de>
Hardware-supplied-by: NJochen Frieling <j.frieling@pengutronix.de>
CC: netdev@vger.kernel.org
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

On resume, before starting the PAL state machine, check if the
adjust_link() method is well supplied. If not, this would lead to a
NULL pointer dereference in the phy_state_machine() function.

This scenario can happen if the Ethernet driver call manually the PHY
functions instead of using the PAL state machine. The mv643xx_eth driver
is a such example.
Signed-off-by: NSimon Guinot <sguinot@lacie.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It was recently brought to my attention that 802.3ad mode bonds would no
longer form when using some network hardware after a driver update.
After snooping around I realized that the particular hardware was using
page-based skbs and found that skb->data did not contain a valid LACPDU
as it was not stored there.  That explained the inability to form an
802.3ad-based bond.  For balance-alb mode bonds this was also an issue
as ARPs would not be properly processed.

This patch fixes the issue in my tests and should be applied to 2.6.36
and as far back as anyone cares to add it to stable.

Thanks to Alexander Duyck <alexander.h.duyck@intel.com> and Jesse
Brandeburg <jesse.brandeburg@intel.com> for the suggestions on this one.
Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
CC: Alexander Duyck <alexander.h.duyck@intel.com>
CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: stable@kerne.org
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Smatch complains because we check whether "pch->chan" is NULL and then
dereference it unconditionally on the next line.  Partly the reason this
bug was introduced is because code was too complicated.  I've simplified
it a little.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>