When programming the start of a periodic output, the code wrongly places
the seconds value into the "low" register and the nanoseconds into the
"high" register.  Even though this is backwards, it slipped through my
testing, because the re-arming code in the interrupt service routine is
correct, and the signal does appear starting with the second edge.

This patch fixes the issue by programming the registers correctly.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Reviewed-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When incoming packet qualifies for rx_copybreak, we copy the data to newly
allocated skb. We do not free/unmap the original buffer. At this point driver
assumes this buffer is unallocated. When enic_rq_alloc_buf() is called for
buffer allocation, it checks if buf->os_buf is NULL. If its not NULL that means
buffer can be re-used.

When vnic_rq_clean() is called for freeing all rq buffers, and if the
rx_copybreak reused buffer falls outside the used desc, we do not free the
buffer. The following trace is observer when dma-debug is enabled.

Fix is to walk through complete ring and clean if buffer is present.

[   40.555386] ------------[ cut here ]------------
[   40.555396] WARNING: CPU: 0 PID: 491 at lib/dma-debug.c:971 dma_debug_device_change+0x188/0x1f0()
[   40.555400] pci 0000:06:00.0: DMA-API: device driver has pending DMA allocations while released from device [count=4]
               One of leaked entries details: [device address=0x00000000ff4cc040] [size=9018 bytes] [mapped with DMA_FROM_DEVICE] [mapped as single]
[   40.555402] Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss oid_registry nfsv4 dns_resolver coretemp intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw joydev mousedev gf128mul hid_generic glue_helper mgag200 usbhid ttm hid drm_kms_helper drm ablk_helper syscopyarea sysfillrect sysimgblt i2c_algo_bit i2c_core iTCO_wdt cryptd mac_hid evdev pcspkr sb_edac edac_core tpm_tis iTCO_vendor_support ipmi_si wmi tpm ipmi_msghandler shpchp lpc_ich processor acpi_power_meter hwmon button ac sch_fq_codel nfs lockd grace sunrpc fscache sd_mod ehci_pci ehci_hcd megaraid_sas usbcore scsi_mod usb_common enic(-) crc32c_generic crc32c_intel btrfs xor raid6_pq ext4 crc16 mbcache jbd2
[   40.555467] CPU: 0 PID: 491 Comm: rmmod Not tainted 4.1.0-rc7-ARCH-01305-gf59b71f #118
[   40.555469] Hardware name: Cisco Systems Inc UCSB-B200-M4/UCSB-B200-M4, BIOS B200M4.2.2.2.23.061220140128 06/12/2014
[   40.555471]  0000000000000000 00000000e2f8a5b7 ffff880275f8bc48 ffffffff8158d6f0
[   40.555474]  0000000000000000 ffff880275f8bca0 ffff880275f8bc88 ffffffff8107b04a
[   40.555477]  ffff8802734e0000 0000000000000004 ffff8804763fb3c0 ffff88027600b650
[   40.555480] Call Trace:
[   40.555488]  [<ffffffff8158d6f0>] dump_stack+0x4f/0x7b
[   40.555492]  [<ffffffff8107b04a>] warn_slowpath_common+0x8a/0xc0
[   40.555494]  [<ffffffff8107b0d5>] warn_slowpath_fmt+0x55/0x70
[   40.555498]  [<ffffffff812fa408>] dma_debug_device_change+0x188/0x1f0
[   40.555503]  [<ffffffff8109aaef>] notifier_call_chain+0x4f/0x80
[   40.555506]  [<ffffffff8109aecb>] __blocking_notifier_call_chain+0x4b/0x70
[   40.555510]  [<ffffffff8109af06>] blocking_notifier_call_chain+0x16/0x20
[   40.555514]  [<ffffffff813f8066>] __device_release_driver+0xf6/0x120
[   40.555518]  [<ffffffff813f8b08>] driver_detach+0xc8/0xd0
[   40.555523]  [<ffffffff813f7c59>] bus_remove_driver+0x59/0xe0
[   40.555527]  [<ffffffff813f93a0>] driver_unregister+0x30/0x70
[   40.555534]  [<ffffffff8131532d>] pci_unregister_driver+0x2d/0xa0
[   40.555542]  [<ffffffffa0200ec2>] enic_cleanup_module+0x10/0x14e [enic]
[   40.555547]  [<ffffffff8110158f>] SyS_delete_module+0x1cf/0x280
[   40.555551]  [<ffffffff811e284e>] ? ____fput+0xe/0x10
[   40.555554]  [<ffffffff810980ec>] ? task_work_run+0xbc/0xf0
[   40.555558]  [<ffffffff815930ee>] system_call_fastpath+0x12/0x71
[   40.555561] ---[ end trace 4988cadc77c2b236 ]---
[   40.555562] Mapped at:
[   40.555563]  [<ffffffff812fa865>] debug_dma_map_page+0x95/0x150
[   40.555566]  [<ffffffffa01f4a88>] enic_rq_alloc_buf+0x1b8/0x360 [enic]
[   40.555570]  [<ffffffffa01f7658>] enic_open+0xf8/0x820 [enic]
[   40.555574]  [<ffffffff8148d50e>] __dev_open+0xce/0x150
[   40.555579]  [<ffffffff8148d851>] __dev_change_flags+0xa1/0x170
Signed-off-by: NGovindarajulu Varadarajan <_govind@gmx.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We do not check the return value of enic_dev_stats_dump(). If allocation
fails, we will hit NULL pointer reference.

Return only if memory allocation fails. For other failures, we return the
previously recorded values.
Signed-off-by: NGovindarajulu Varadarajan <_govind@gmx.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There is a small window between vnic_intr_unmask() and enic_poll_unlock_napi().
In this window if an irq occurs and napi is scheduled on different cpu, it tries
to acquire enic_poll_lock_napi() and hits the following WARN_ON message.

Fix is to unlock napi_poll before unmasking the interrupt.

[  781.121746] ------------[ cut here ]------------
[  781.121789] WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/cisco/enic/vnic_rq.h:228 enic_poll_msix_rq+0x36a/0x3c0 [enic]()
[  781.121834] Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss oid_registry nfsv4 dns_resolver coretemp intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel mgag200 ttm drm_kms_helper joydev aes_x86_64 lrw drm gf128mul mousedev glue_helper sb_edac ablk_helper iTCO_wdt iTCO_vendor_support evdev ipmi_si syscopyarea sysfillrect sysimgblt i2c_algo_bit i2c_core edac_core lpc_ich mac_hid cryptd pcspkr ipmi_msghandler shpchp tpm_tis acpi_power_meter tpm wmi processor hwmon button ac sch_fq_codel nfs lockd grace sunrpc fscache hid_generic usbhid hid ehci_pci ehci_hcd sd_mod megaraid_sas usbcore scsi_mod usb_common enic crc32c_generic crc32c_intel btrfs xor raid6_pq ext4 crc16 mbcache jbd2
[  781.122176] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.1.0-rc6-ARCH-00040-gc46a024e-dirty #106
[  781.122210] Hardware name: Cisco Systems Inc UCSB-B200-M4/UCSB-B200-M4, BIOS B200M4.2.2.2.23.061220140128 06/12/2014
[  781.122252]  0000000000000000 bddbbc9d655ec96e ffff880277e43da8 ffffffff81583fe8
[  781.122286]  0000000000000000 0000000000000000 ffff880277e43de8 ffffffff8107acfa
[  781.122319]  ffff880272c01000 ffff880273f18000 ffff880273f1a100 0000000000000000
[  781.122352] Call Trace:
[  781.122364]  <IRQ>  [<ffffffff81583fe8>] dump_stack+0x4f/0x7b
[  781.122399]  [<ffffffff8107acfa>] warn_slowpath_common+0x8a/0xc0
[  781.122425]  [<ffffffff8107ae2a>] warn_slowpath_null+0x1a/0x20
[  781.122455]  [<ffffffffa01fa9ca>] enic_poll_msix_rq+0x36a/0x3c0 [enic]
[  781.122487]  [<ffffffff8148525a>] net_rx_action+0x22a/0x370
[  781.122512]  [<ffffffff8107ed3d>] __do_softirq+0xed/0x2d0
[  781.122537]  [<ffffffff8107f06e>] irq_exit+0x7e/0xa0
[  781.122560]  [<ffffffff8158c424>] do_IRQ+0x64/0x100
[  781.122582]  [<ffffffff8158a42e>] common_interrupt+0x6e/0x6e
[  781.122605]  <EOI>  [<ffffffff810bd331>] ? cpu_startup_entry+0x121/0x480
[  781.122638]  [<ffffffff810bd2fc>] ? cpu_startup_entry+0xec/0x480
[  781.122667]  [<ffffffff810f2ed3>] ? clockevents_register_device+0x113/0x1f0
[  781.122698]  [<ffffffff81050ab6>] start_secondary+0x196/0x1e0
[  781.122723] ---[ end trace cec2e9dd3af7b9db ]---
Signed-off-by: NGovindarajulu Varadarajan <_govind@gmx.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The RGMII block is currently only powered on when using RGMII or
RGMII_NO_ID, which is not correct when using the GENET interface in MII
or Reverse MII modes. We always need to power on the RGMII interface for
this block to properly work, regardless of the MII mode in which we
operate.

Fixes: aa09677c ("net: bcmgenet: add MDIO routines")
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When the driver gets unregistered a call to netif_napi_del() was
missing, this all was also missing in the error paths of
b44_init_one().
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There are several places in the driver (all in control paths) where
coherent dma memory is being allocated using either dma_alloc_coherent()
or the deprecated pci_alloc_consistent(). All these calls should be
changed to use dma_zalloc_coherent() to avoid uninitialized fields in
data structures backed by this memory.
Reported-by: NJoerg Roedel <jroedel@suse.de>
Tested-by: NJoerg Roedel <jroedel@suse.de>
Signed-off-by: NSriharsha Basavapatna <sriharsha.basavapatna@avagotech.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since the Tx timer function runs in softirq context the driver needs
to call disable_irq_nosync instead of a disable_irq.
Reported-by: NJosh Stone <jistone@redhat.com>
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If SRIOV is enabled we need to be in VEB mode not VEPA mode at probe.
This fixes an NPAR bug when SRIOV is enabled in the BIOS.

Change-ID: Ibf006abafd9a0ca3698ec24848cd771cf345cbbc
Signed-off-by: NAnjali Singhai Jain <anjali.singhai@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

The patch fixes a bug in the default configuration which
prevented a software bridge loaded on the PF interface from
working correctly because broadcast packets are incorrectly
looped back.

Fix the general case, by loading the driver in VEPA mode Until a
VF or VMDq VSI is added. This way loopback on the Main VSI is
turned off until needed and can resolve the issue of unnecessary
reflection for users that do not have VF or VMDq VSIs setup.

The driver must now coordinate the loopback setting for the Flow
Director (FDIR) VSI to make sure it is in sync with the current
VEB or VEPA mode setting.

The user can still switch bridge modes from the bridge commands and
choose to be in VEPA mode with VF VSIs. Because of hardware
requirements, the call to switch to VEB mode when no VF/VMDqs are
present will be rejected.

NOTE: This patch uses BIT_ULL as that is preferred going forward,
a followup patch in the lower priority queue to net-next will fix
up the remaining 1 << usages.

Change-ID: Ib121ddb18fe4b3c4f52e9deda6fcbeb9105683d1
Signed-off-by: NAnjali Singhai Jain <anjali.singhai@intel.com>
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

This patch fixes a bug where the i40e Tx queue will hang if this
skb is passed to the driver.

With mixed size fragments while using TSO there was a corner case
where we needed to linearize but we were not. This was seen with
iSCSI traffic and could be reproduced with a frag list that looks
like this:

num_frags = 17, gso_segs = 17, hdr_len = 66,
skb_shinfo(skb)->gso_size = 1448
size = 3002, j = 1, frag_size = 2936, num_frags = 17
size = 4268, j = 1, frag_size = 4096, num_frags = 16
size = 5534, j = 1, frag_size = 4096, num_frags = 15
size = 5352, j = 1, frag_size = 4096, num_frags = 14
size = 5170, j = 1, frag_size = 4096, num_frags = 13
size = 3468, j = 1, frag_size = 2576, num_frags = 12
size = 750, j = 1, frag_size = 112, num_frags = 11
size = 862, j = 2, frag_size = 112, num_frags = 10
size = 974, j = 3, frag_size = 112, num_frags = 9
size = 1126, j = 4, frag_size = 152, num_frags = 8
size = 1330, j = 5, frag_size = 204, num_frags = 7
size = 1534, j = 6, frag_size = 204, num_frags = 6
size = 356, j = 1, frag_size = 204, num_frags = 5
size = 560, j = 2, frag_size = 204, num_frags = 4
size = 764, j = 3, frag_size = 204, num_frags = 3
size = 968, j = 4, frag_size = 204, num_frags = 2
size = 1140, j = 5, frag_size = 172, num_frags = 1
result: linearize = 0, j = 6

Change-ID: I79bb1aeab0af255fe2ce28e93672a85d85bf47e8
Signed-off-by: NAnjali Singhai Jain <anjali.singhai@intel.com>
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Commit dff173de ("bnx2x: Fix statistics locking scheme") changed the
bnx2x locking around statistics state into using a mutex - but the lock
is being accessed via a timer which is forbidden.

[If compiled with CONFIG_DEBUG_MUTEXES, logs show a warning about
accessing the mutex in interrupt context]

This moves the implementation into using a semaphore [with size '1']
instead.
Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: NAriel Elior <Ariel.Elior@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When we come to tear things down in netback_remove() and generate the
uevent it is possible that the xenstore directory has already been
removed (details below).

In such cases netback_uevent() won't be able to read the hotplug
script and will write a xenstore error node.

A recent change to the hypervisor exposed this race such that we now
sometimes lose it (where apparently we didn't ever before).

Instead read the hotplug script configuration during setup and use it
for the lifetime of the backend device.

The apparently more obvious fix of moving the transition to
state=Closed in netback_remove() to after the uevent does not work
because it is possible that we are already in state=Closed (in
reaction to the guest having disconnected as it shutdown). Being
already in Closed means the toolstack is at liberty to start tearing
down the xenstore directories. In principal it might be possible to
arrange to unregister the device sooner (e.g on transition to Closing)
such that xenstore would still be there but this state machine is
fragile and prone to anger...

A modern Xen system only relies on the hotplug uevent for driver
domains, when the backend is in the same domain as the toolstack it
will run the necessary setup/teardown directly in the correct sequence
wrt xenstore changes.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Acked-by: NWei Liu <wei.liu2@citrix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

drivers/net/xen-netback/netback.c: In function ‘xenvif_tx_build_gops’:
drivers/net/xen-netback/netback.c:1253:8: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘int’ [-Wformat=]
        (txreq.offset&~PAGE_MASK) + txreq.size);
        ^

PAGE_MASK's type can vary by arch, so a cast is needed.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
----
v2: Cast to unsigned long, since PAGE_MASK can vary by arch.
Acked-by: NWei Liu <wei.liu2@citrix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When Rx packet data must be dropped, all the buffers
associated with that Rx packet must be freed. Extend
and rename efx_free_rx_buffer() to efx_free_rx_buffers()
and loop through all the fragments.
By doing so this patch fixes a possible memory leak.
Signed-off-by: NShradha Shah <sshah@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Bug in the driver initialization causes soft-lockup if firmware
initialization timeout is reached. Polling function bfa_ioc_poll_fwinit()
incorrectly calls bfa_nw_iocpf_timeout() when the timeout is reached.
The problem is that bfa_nw_iocpf_timeout() calls again
bfa_ioc_poll_fwinit()... etc. The bfa_ioc_poll_fwinit() should directly
send timeout event for iocpf and the same should be done if firmware
download into HW fails.

Cc: Rasesh Mody <rasesh.mody@qlogic.com>
Signed-off-by: NIvan Vecera <ivecera@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Driver starts iocpf timer prior bnad_ioceth_enable() call and this is
unreasonable. This piece of code probably originates from Brocade/Qlogic
out-of-box driver during initial import into upstream. This driver uses
only one timer and queue to implement multiple timers and this timer is
started at this place. The upstream driver uses multiple timers instead
of this.

Cc: Rasesh Mody <rasesh.mody@qlogic.com>
Signed-off-by: NIvan Vecera <ivecera@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Firmware required by bna is stored in appropriate files as sequence
of LE32 integers. After loading by request_firmware() they need to be
byte-swapped on big-endian arches. Without this conversion the NIC
is unusable on big-endian machines.

Cc: Rasesh Mody <rasesh.mody@qlogic.com>
Signed-off-by: NIvan Vecera <ivecera@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The function brcmf_msgbuf_get_pktid() may return a NULL pointer so
the callers should check the return pointer before accessing it to
avoid the crash below (see [1]):

brcmfmac: brcmf_msgbuf_get_pktid: Invalid packet id 273 (not in use)
BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
IP: [<ffffffff8145b225>] skb_pull+0x5/0x50
PGD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: pci_stub vboxpci(O) vboxnetflt(O) vboxnetadp(O) vboxdrv(O)
 snd_hda_codec_hdmi bnep mousedev hid_generic ushwmon msr ext4 crc16 mbcache
 jbd2 sd_mod uas usb_storage ahci libahci libata scsi_mod xhci_pci xhci_hcd
 usbcore usb_common
CPU: 0 PID: 1661 Comm: irq/61-brcmf_pc Tainted: G O    4.0.1-MacbookPro-ARCH #1
Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6,
 BIOS MBP121.88Z.0167.B02.1503241251 03/24/2015
task: ffff880264203cc0 ti: ffff88025ffe4000 task.ti: ffff88025ffe4000
RIP: 0010:[<ffffffff8145b225>]  [<ffffffff8145b225>] skb_pull+0x5/0x50
RSP: 0018:ffff88025ffe7d40  EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffff88008a33c000 RCX: 0000000000000044
RDX: 0000000000000000 RSI: 000000000000004a RDI: 0000000000000000
RBP: ffff88025ffe7da8 R08: 0000000000000096 R09: 000000000000004a
R10: 0000000000000000 R11: 000000000000048e R12: ffff88025ff14f00
R13: 0000000000000000 R14: ffff880263b48200 R15: ffff88008a33c000
FS:  0000000000000000(0000) GS:ffff88026ec00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000080 CR3: 000000000180b000 CR4: 00000000003407f0
Stack:
 ffffffffa06aed74 ffff88025ffe7dc8 ffff880263b48270 ffff880263b48278
 05ea88020000004a 0002ffff81014635 000000001720b2f6 ffff88026ec116c0
 ffff880263b48200 0000000000010000 ffff880263b4ae00 ffff880264203cc0
Call Trace:
 [<ffffffffa06aed74>] ? brcmf_msgbuf_process_rx+0x404/0x480 [brcmfmac]
 [<ffffffff810cea60>] ? irq_finalize_oneshot.part.30+0xf0/0xf0
 [<ffffffffa06afb55>] brcmf_proto_msgbuf_rx_trigger+0x35/0xf0 [brcmfmac]
 [<ffffffffa06baf2a>] brcmf_pcie_isr_thread_v2+0x8a/0x130 [brcmfmac]
 [<ffffffff810cea80>] irq_thread_fn+0x20/0x50
 [<ffffffff810ceddf>] irq_thread+0x13f/0x170
 [<ffffffff810cebf0>] ? wake_threads_waitq+0x30/0x30
 [<ffffffff810ceca0>] ? irq_thread_dtor+0xb0/0xb0
 [<ffffffff81092a08>] kthread+0xd8/0xf0
 [<ffffffff81092930>] ? kthread_create_on_node+0x1c0/0x1c0
 [<ffffffff8156d898>] ret_from_fork+0x58/0x90
 [<ffffffff81092930>] ? kthread_create_on_node+0x1c0/0x1c0
Code: 01 83 e2 f7 88 50 01 48 83 c4 08 5b 5d f3 c3 0f 1f 80 00 00 00 00 83 e2
 f7 88 50 01 c3 66 0f 1f 84 00 00 00 00 00 0f 1f
RIP  [<ffffffff8145b225>] skb_pull+0x5/0x50
 RSP <ffff88025ffe7d40>
CR2: 0000000000000080
---[ end trace b074c0f90e7c997d ]---

[1] http://mid.gmane.org/20150430193259.GA5630@googlemail.com

Cc: <stable@vger.kernel.org> # v3.18, v3.19, v4.0, v4.1
Reported-by: NMichael Hornung <mhornung.linux@gmail.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The radio cfg DWORD was taken from the wrong place in the
8000 HW family, after a line in the code was wrongly changed
by mistake. This broke several 8260 devices.

Fixes: 5dd9c68a ("iwlwifi: drop support for early versions of 8000")
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The cmd_in_flight tracking was introduced to workaround faulty
power management hardware, by having the driver keep the NIC
awake as long as there are commands in flight. However, some of
the code handling this workaround was unconditionally executed,
which resulted with an inconsistent state where the driver assumed
that the NIC was awake although it wasn't.

Fix this by renaming 'cmd_in_flight' to 'cmd_hold_nic_awake' and
handling the NIC requested awake state only for hardwares for
which the workaround is needed.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

da91309e (cpumask: Utility function to set n'th cpu...) created a
genuinely weird function.  I never saw it before, it went through DaveM.
(He only does this to make us other maintainers feel better about our own
mistakes.)

cpumask_set_cpu_local_first's purpose is say "I need to spread things
across N online cpus, choose the ones on this numa node first"; you call
it in a loop.

It can fail.  One of the two callers ignores this, the other aborts and
fails the device open.

It can fail in two ways: allocating the off-stack cpumask, or through a
convoluted codepath which AFAICT can only occur if cpu_online_mask
changes.  Which shouldn't happen, because if cpu_online_mask can change
while you call this, it could return a now-offline cpu anyway.

It contains a nonsensical test "!cpumask_of_node(numa_node)".  This was
drawn to my attention by Geert, who said this causes a warning on Sparc.
It sets a single bit in a cpumask instead of returning a cpu number,
because that's what the callers want.

It could be made more efficient by passing the previous cpu rather than
an index, but that would be more invasive to the callers.

Fixes: da91309e
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (then rebased)
Tested-by: NAmir Vadai <amirv@mellanox.com>
Acked-by: NAmir Vadai <amirv@mellanox.com>
Acked-by: NDavid S. Miller <davem@davemloft.net>

xennet_remove() freed the queues before freeing the netdevice which
results in a use-after-free when free_netdev() tries to delete the
napi instances that have already been freed.

Fix this by fully destroy the queues (which includes deleting the napi
instances) before freeing the netdevice.
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The test in mlx4_load_one() to remove MLX4_FLAG_MSI_X expects mlx4_NOP() to
fail with -EBUSY. It is also necessary to avoid the reset since the device
is not fully reinitialized before calling mlx4_start_hca() a second time.

Note that this will also affect mlx4_test_interrupts(), the only other user
of MLX4_CMD_NOP.

Fixes: f5aef5aa ("net/mlx4_core: Activate reset flow upon fatal command cases")
Signed-off-by: NBenjamin Poirier <bpoirier@suse.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit e9ce7cb6 ("xen-netback: Factor queue-specific data into queue
struct") introduced a regression when moving queue-specific data into
the queue struct by failing to set the credit_bytes field. This
prevented bandwidth limiting from working. Initialize the field as it
was done before multiqueue support was added.
Signed-off-by: NRoss Lagerwall <ross.lagerwall@citrix.com>
Acked-by: NWei Liu <wei.liu2@citrix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If read() syscall requests unexpected number of bytes from "dimm" binary
attribute file, return EINVAL instead of EPERM.

At the same time pin down sysfs file size to the fixed
sizeof(struct netxen_dimm_cfg), which allows to exploit some missing
sanity checks from kernfs (file boundary checks vs offset etc.)
Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When the ethtool command is used to set the speed of the device while
the device is down, the check to set the initial mode may fail when
the device is brought up, causing failure to bring the device up.

Update the code to set the initial mode based on the desired speed if
auto-negotiation is disabled.

This patch fixes a bug introduced by:
d9663c8c ("amd-xgbe-phy: Use phydev advertising field vs supported")
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A pair of nested spin locks was introduced in commit 63502b8d
"dp83640: Fix receive timestamp race condition".

Unfortunately the 'flags' parameter was reused for the inner lock,
clobbering the originally saved IRQ state.  This patch fixes the issue
by changing the inner lock to plain spin_lock without irqsave.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Callers of the ext_write function are supposed to hold a mutex that
protects the state of the dialed page, but one caller was missing the
lock from the very start, and over time the code has been changed
without following the rule.  This patch cleans up the call sites in
violation of the rule.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently, the calibration function that corrects the initial offsets
among multiple devices only works the first time.  If the function is
called more than once, the calibration fails and bogus offsets will be
programmed into the devices.

In a well hidden spot, the device documentation tells that trigger indexes
0 and 1 are special in allowing the TRIG_IF_LATE flag to actually work.

This patch fixes the issue by using one of the special triggers during the
recalibration method.
Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

stmmac DebugFS entries are currently global to the driver. As a result,
having more than one stmmac device in the system creates the following
error:
* ERROR stmmaceth, debugfs create directory failed
* stmmac_hw_setup: failed debugFS registration

This also results in being able to access the debugfs information for
the first registered device only.

This patch changes the debugfs structure to have one sub-directory per
net-device. Files under "/sys/kernel/debug/stmmaceth" will now show-up
under /sys/kernel/debug/stmmaceth/ethN/.
Signed-off-by: NMathieu Olivari <mathieu@codeaurora.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix in send of emac regs dump to ethtool which
causing in wrong data interpretation on ethtool
layer for MII and EMAC.
Signed-off-by: NIvan Mikhaylov <ivan@ru.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

While adding support for 7425 PHY in the 7xxx PHY driver, the ID that
was used was actually coming from an external PHY: a BCM5461x. Fix this
by using the proper ID for the internal 7425 PHY and set the
PHY_IS_INTERNAL flag, otherwise consumers of this PHY driver would not
be able to properly identify it as such.

Fixes: d068b02c ("net: phy: add BCM7425 and BCM7429 PHYs")
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NPetri Gynther <pgynther@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

According to the Zynq TRM, gigabit half duplex is not supported.  Add a
new cap and compatible string so Zynq can avoid advertising that mode.
Signed-off-by: NNathan Sullivan <nathan.sullivan@ni.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The tx_curr_frame_payload field is u32. When we try to calculate a
small negative delta based on it, we end up with a positive integer
close to 2^32 instead.  So the tx_bytes pointer increases by about
2^32 for every transmitted frame.

Fix by calculating the delta as a signed long.

Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Reported-by: NFlorian Bruhin <me@the-compiler.org>
Fixes: 7a1e890e ("usbnet: Fix tx_bytes statistic running backward in cdc_ncm")
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

qos_seq points (to a struct) inside the command response data.

Make sure to free the response only after qos_seq is not
needed anymore.
Reported-by: NHeng Luo <heng.luo@intel.com>
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If the device is reset during suspend with net-detect enabled, we
leave the net-detect information dangling and this causes the next
suspend to fail with a warning:

[21795.351010] WARNING: at /root/iwlwifi/iwlwifi-stack-dev/drivers/net/wireless/iwlwifi/mvm/d3.c:989 __iwl_mvm_suspend.isra.6+0x2be/0x460 [iwlmvm]()
[21795.353253] Modules linked in: iwlmvm(O) iwlwifi(O) mac80211(O) cfg80211(O) compat(O) [...]
[21795.366168] CPU: 1 PID: 3645 Comm: bash Tainted: G           O 3.10.29-dev #1
[21795.368785] Hardware name: Dell Inc. Latitude E6430/0CPWYR, BIOS A09 12/13/2012
[21795.371441]  f8ec6748 f8ec6748 e51f3ce8 c168aa62 e51f3d10 c103a824 c1871238 f8ec6748
[21795.374228]  000003dd f8eb982e f8eb982e 00000000 c3408ed4 c41edbbc e51f3d20 c103a862
[21795.377006]  00000009 00000000 e51f3da8 f8eb982e c41ee3dc 00000004 e7970000 e51f3d74
[21795.379792] Call Trace:
[21795.382461]  [<c168aa62>] dump_stack+0x16/0x18
[21795.385133]  [<c103a824>] warn_slowpath_common+0x64/0x80
[21795.387803]  [<f8eb982e>] ? __iwl_mvm_suspend.isra.6+0x2be/0x460 [iwlmvm]
[21795.390485]  [<f8eb982e>] ? __iwl_mvm_suspend.isra.6+0x2be/0x460 [iwlmvm]
[21795.393124]  [<c103a862>] warn_slowpath_null+0x22/0x30
[21795.395787]  [<f8eb982e>] __iwl_mvm_suspend.isra.6+0x2be/0x460 [iwlmvm]
[21795.398464]  [<f8eb9d7c>] iwl_mvm_suspend+0xec/0x140 [iwlmvm]
[21795.401127]  [<c104be11>] ? del_timer_sync+0xa1/0xc0
[21795.403800]  [<f8d4107e>] __ieee80211_suspend+0x1de/0xff0 [mac80211]
[21795.406459]  [<c168e43d>] ? mutex_lock_nested+0x25d/0x350
[21795.409084]  [<c1586b64>] ? rtnl_lock+0x14/0x20
[21795.411685]  [<f8cf0076>] ieee80211_suspend+0x16/0x20 [mac80211]
[21795.414318]  [<f8c4e014>] wiphy_suspend+0x74/0x710 [cfg80211]
[21795.416916]  [<c141e612>] __device_suspend+0x1e2/0x220
[21795.419521]  [<f8c4dfa0>] ? addresses_show+0xa0/0xa0 [cfg80211]
[21795.422097]  [<c141f997>] dpm_suspend+0x67/0x210
[21795.424661]  [<c141fd6f>] dpm_suspend_start+0x4f/0x60
[21795.427219]  [<c108d8e0>] suspend_devices_and_enter+0x60/0x480
[21795.429768]  [<c168646a>] ? printk+0x4d/0x4f
[21795.432295]  [<c108de76>] pm_suspend+0x176/0x210
[21795.434830]  [<c108ca5d>] state_store+0x5d/0xb0
[21795.437410]  [<c108ca00>] ? wakeup_count_show+0x50/0x50
[21795.439961]  [<c13208db>] kobj_attr_store+0x1b/0x30
[21795.442514]  [<c11e3a4b>] sysfs_write_file+0xab/0x100
[21795.445088]  [<c11e39a0>] ? sysfs_poll+0xa0/0xa0
[21795.447659]  [<c1179655>] vfs_write+0xa5/0x1c0
[21795.450212]  [<c1179af7>] SyS_write+0x57/0xa0
[21795.452699]  [<c1699ec1>] sysenter_do_call+0x12/0x32
[21795.455146] ---[ end trace faf5321baba2bfdb ]---

To fix this, call the iwl_mvm_free_nd() function in case of any error
during resume.  Additionally, rename the "out_unlock" label to err to
make it clearer that it's only called in error conditions.

Cc: stable@vger.kernel.org [3.19+]
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The __iwl_mvm_resume() function always returns 1, which causes
mac80211 to do a reconfig with IEEE80211_RECONFIG_TYPE_RESTART.  This
type of reconfig calls iwl_mvm_restart_complete(), where we unref the
IWL_MVM_REF_UCODE_DOWN, so we should always take the reference in this
case.

This prevents this kind of warning from happening:

[40026.103025] WARNING: at /root/iwlwifi/iwlwifi-stack-dev/drivers/net/wireless/iwlwifi/mvm/mac80211.c:236 iwl_mvm_unref+0xc9/0xd0 [iwlmvm]()
[40026.105145] Modules linked in: iwlmvm(O) iwlwifi(O) mac80211(O) cfg80211(O) compat(O) ctr ccm arc4 autofs4 snd_hda_codec_hdmi snd_hda_codec_idt joydev coretemp kvm_intel kvm aesni_intel ablk_helper cryptd lrw aes_i586 snd_hda_intel xts snd_hda_codec gf128mul snd_hwdep snd_pcm snd_seq_midi dell_wmi snd_rawmidi sparse_keymap snd_seq_midi_event snd_seq uvcvideo dell_laptop videobuf2_core dcdbas microcode videodev psmouse snd_timer videobuf2_vmalloc videobuf2_memops serio_raw snd_seq_device btusb i915 snd bluetooth lpc_ich drm_kms_helper soundcore snd_page_alloc drm i2c_algo_bit wmi parport_pc ppdev video binfmt_misc rpcsec_gss_krb5 nfsd mac_hid nfs_acl nfsv4 auth_rpcgss nfs fscache lockd sunrpc msdos lp parport sdhci_pci sdhci ahci libahci e1000e mmc_core ptp pps_core [last unloaded: compat]
[40026.117640] CPU: 2 PID: 3827 Comm: bash Tainted: G        W  O 3.10.29-dev #1
[40026.120216] Hardware name: Dell Inc. Latitude E6430/0CPWYR, BIOS A09 12/13/2012
[40026.122815]  f8effd18 f8effd18 e740fd18 c168aa62 e740fd40 c103a824 c1871238 f8effd18
[40026.125527]  000000ec f8ec79c9 f8ec79c9 d5d29ba4 d5d2a20c 00000000 e740fd50 c103a862
[40026.128209]  00000009 00000000 e740fd7c f8ec79c9 f1c591c4 00000400 00000000 f8efb490
[40026.130886] Call Trace:
[40026.133506]  [<c168aa62>] dump_stack+0x16/0x18
[40026.136115]  [<c103a824>] warn_slowpath_common+0x64/0x80
[40026.138727]  [<f8ec79c9>] ? iwl_mvm_unref+0xc9/0xd0 [iwlmvm]
[40026.141319]  [<f8ec79c9>] ? iwl_mvm_unref+0xc9/0xd0 [iwlmvm]
[40026.143881]  [<c103a862>] warn_slowpath_null+0x22/0x30
[40026.146453]  [<f8ec79c9>] iwl_mvm_unref+0xc9/0xd0 [iwlmvm]
[40026.149030]  [<f8ec7a4d>] iwl_mvm_mac_reconfig_complete+0x7d/0x210 [iwlmvm]
[40026.151645]  [<f8b74b20>] ? ftrace_raw_event_drv_reconfig_complete+0xc0/0xe0 [mac80211]
[40026.154291]  [<f8b6769e>] ieee80211_reconfig+0x28e/0x2620 [mac80211]
[40026.156920]  [<c10ef0ea>] ? ring_buffer_unlock_commit+0xba/0x100
[40026.159585]  [<f8b4a04d>] ieee80211_resume+0x6d/0x80 [mac80211]
[40026.162206]  [<f8a79722>] wiphy_resume+0x72/0x260 [cfg80211]
[40026.164799]  [<c141e2e7>] ? device_resume+0x57/0x150
[40026.167425]  [<f8a796b0>] ? wiphy_suspend+0x710/0x710 [cfg80211]
[40026.170075]  [<c141e26e>] dpm_run_callback+0x2e/0x50
[40026.172695]  [<c141e321>] device_resume+0x91/0x150
[40026.175334]  [<c141f636>] dpm_resume+0xf6/0x200
[40026.177922]  [<c141f920>] dpm_resume_end+0x10/0x20
[40026.180489]  [<c108d9f7>] suspend_devices_and_enter+0x177/0x480
[40026.183037]  [<c168646a>] ? printk+0x4d/0x4f
[40026.185559]  [<c108de76>] pm_suspend+0x176/0x210
[40026.188065]  [<c108ca5d>] state_store+0x5d/0xb0
[40026.190581]  [<c108ca00>] ? wakeup_count_show+0x50/0x50
[40026.193052]  [<c13208db>] kobj_attr_store+0x1b/0x30
[40026.195608]  [<c11e3a4b>] sysfs_write_file+0xab/0x100
[40026.198055]  [<c11e39a0>] ? sysfs_poll+0xa0/0xa0
[40026.200469]  [<c1179655>] vfs_write+0xa5/0x1c0
[40026.202893]  [<c1179af7>] SyS_write+0x57/0xa0
[40026.205245]  [<c1699ec1>] sysenter_do_call+0x12/0x32
[40026.207619] ---[ end trace db1d5a72a0381b0a ]---
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NEliadX Peller <eliad@wizery.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

There are buses that can't handle ASYNC command without
copying them. Duplicate the host command instead.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Take the MAC address from the OTP even if one is present in
the NVM, if that MAC address happens to be a reserved one.
Signed-off-by: NLiad Kaufman <liad.kaufman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>