- 02 Sep, 2014 7 commits
-
-
Wangzhao Cai authored
commit 30c6fd42 upstream. I am using a USB keyborad that give me "usb_submit_urb(ctrl) failed: -1" error when I plugin it. and I need to wait for 10s for this device to be ready. By adding this quirks, the usb keyborad is usable right after plugin Signed-off-by: Wangzhao Cai <microcaicai@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Jiang Liu authored
commit c5946f9d upstream. The assigned IRQ should be freed before calling pci_disable_device() when shutting down system, otherwise it will cause following warning. [ 568.879482] ------------[ cut here ]------------ [ 568.884236] WARNING: CPU: 1 PID: 3300 at /home/konrad/ssd/konrad/xtt-i386/bootstrap/linux-usb/fs/proc/generic.c:521 remove_proc_entry+0x165/0x170() [ 568.897846] remove_proc_entry: removing non-empty directory 'irq/16', leaking at least 'ohci_hcd:usb4' [ 568.907430] Modules linked in: dm_multipath dm_mod iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c_generic sg sd_mod crct10dif_generic crc_t10dif crct10dif_common radeon fbcon tileblit ttm font bitblit softcursor ata_generic ahci libahci drm_kms_helper skge r8169 libata mii scsi_mod wmi acpi_cpufreq [ 568.938539] CPU: 1 PID: 3300 Comm: init Tainted: G W 3.16.0-rc5upstream-01651-g03b9189 #1 [ 568.947946] Hardware name: ECS A780GM-A Ultra/A780GM-A Ultra, BIOS 080015 04/01/2010 [ 568.956008] 00000209 ed0f1cd0 c1617946 c175403c ed0f1d00 c1090c3f c1754084 ed0f1d2c [ 568.964068] 00000ce4 c175403c 00000209 c11f22a5 c11f22a5 f755e8c0 ed0f1d78 f755e90d [ 568.972128] ed0f1d18 c1090cde 00000009 ed0f1d10 c1754084 ed0f1d2c ed0f1d60 c11f22a5 [ 568.980194] Call Trace: [ 568.982715] [<c1617946>] dump_stack+0x48/0x60 [ 568.987294] [<c1090c3f>] warn_slowpath_common+0x7f/0xa0 [ 569.003887] [<c1090cde>] warn_slowpath_fmt+0x2e/0x30 [ 569.009092] [<c11f22a5>] remove_proc_entry+0x165/0x170 [ 569.014476] [<c10da6ca>] unregister_irq_proc+0xaa/0xc0 [ 569.019858] [<c10d582f>] free_desc+0x1f/0x60 [ 569.024346] [<c10d58aa>] irq_free_descs+0x3a/0x80 [ 569.029283] [<c10d9e9d>] irq_dispose_mapping+0x2d/0x50 [ 569.034666] [<c1078fd3>] mp_unmap_irq+0x73/0xa0 [ 569.039423] [<c107196b>] acpi_unregister_gsi_ioapic+0x2b/0x40 [ 569.045431] [<c107180f>] acpi_unregister_gsi+0xf/0x20 [ 569.050725] [<c1339cad>] acpi_pci_irq_disable+0x4b/0x50 [ 569.056196] [<c14daa38>] pcibios_disable_device+0x18/0x20 [ 569.061848] [<c130123d>] do_pci_disable_device+0x4d/0x60 [ 569.067410] [<c13012b7>] pci_disable_device+0x47/0xb0 [ 569.077814] [<c14800b1>] usb_hcd_pci_shutdown+0x31/0x40 [ 569.083285] [<c1304b19>] pci_device_shutdown+0x19/0x50 [ 569.088667] [<c13fda64>] device_shutdown+0x14/0x120 [ 569.093777] [<c10ac29d>] kernel_restart_prepare+0x2d/0x30 [ 569.099429] [<c10ac41e>] kernel_restart+0xe/0x60 [ 569.109028] [<c10ac611>] SYSC_reboot+0x191/0x220 [ 569.159269] [<c10ac6ba>] SyS_reboot+0x1a/0x20 [ 569.163843] [<c161c718>] sysenter_do_call+0x12/0x16 [ 569.168951] ---[ end trace ccc1ec4471c289c9 ]--- Tested-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
James P Michels III authored
commit cd83ce9e upstream. This patch adds a usb quirk to support devices with interupt endpoints and bInterval values expressed as microframes. The quirk causes the parse endpoint function to modify the reported bInterval to a standards conforming value. There is currently code in the endpoint parser that checks for bIntervals that are outside of the valid range (1-16 for USB 2+ high speed and super speed interupt endpoints). In this case, the code assumes the bInterval is being reported in 1ms frames. As well, the correction is only applied if the original bInterval value is out of the 1-16 range. With this quirk applied to the device, the bInterval will be accurately adjusted from microframes to an exponent. Signed-off-by: James P Michels III <james.p.michels@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Joonyoung Shim authored
commit 526a4045 upstream. The usb device will autoresume from choose_wakeup() if it is autosuspended with the wrong wakeup setting, but below errors occur because usb3503 misc driver will switch to standby mode when suspended. As add USB_QUIRK_RESET_RESUME, it can stop setting wrong wakeup from autosuspend_check(). [ 7.734717] usb 1-3: reset high-speed USB device number 3 using exynos-ehci [ 7.854658] usb 1-3: device descriptor read/64, error -71 [ 8.079657] usb 1-3: device descriptor read/64, error -71 [ 8.294664] usb 1-3: reset high-speed USB device number 3 using exynos-ehci [ 8.414658] usb 1-3: device descriptor read/64, error -71 [ 8.639657] usb 1-3: device descriptor read/64, error -71 [ 8.854667] usb 1-3: reset high-speed USB device number 3 using exynos-ehci [ 9.264598] usb 1-3: device not accepting address 3, error -71 [ 9.374655] usb 1-3: reset high-speed USB device number 3 using exynos-ehci [ 9.784601] usb 1-3: device not accepting address 3, error -71 [ 9.784838] usb usb1-port3: device 1-3 not suspended yet Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Preston Fick authored
commit 934ef5ac upstream. This `usb_reset_device` command has been around since the driver was originally reverse engineered. It doesn't cause much issue on single interface CP210x devices, but on the CP2105 and CP2108 with 2 and 4 interfaces respectively it will cause instability on enumeration and delays enumeration noticably. There should be no reason to reset a device at startup, per the CP210x AN571 spec. Signed-off-by: Preston Fick <preston.fick@silabs.com> Cc: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Daniel Mack authored
commit 50aea6fc upstream. The musb/cppi41 code installs a hrtimer to work around DMA completion interrupts that have fired too early on AM335x hardware. This timer is currently programmed to first fire 140 microseconds after the DMA completion callback. According to the commit which introduced it (a655f481, "usb: musb: musb_cppi41: handle pre-mature TX complete interrupt"), that value is is considered a 'rule of thumb' that worked well with the test case described in the commit log. Test show, however, that for USB audio devices and much smaller packet sizes, the timer has to fire earlier in order to correctly handle the audio stream. The original test case had output transfer sizes of 1514 bytes, and a delay of 140 microseconds. For audio devices with 24 bytes channel size, 3 microseconds seem to work well. Hence, let's assume that the time it takes to clear the bit correlates with the number of bytes transferred. The referenced commit log mentions such a suspicion as well. Let the timer fire in cppi41_channel->total_len/10 microseconds to correctly handle both cases. Also, shorten the interval in which the timer fires again in case of a non-empty early_tx list. With these changes in place, both FS and HS audio devices appear to work well on AM335x hardware. Signed-off-by: Daniel Mack <zonque@gmail.com> Reported-by: Sebastian Reimers <sebastian.reimers@googlemail.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Kent Overstreet authored
commit b3fa7e77 upstream. The real fix is where we check the bytes we need against how much is remaining - we also need to check for a journal entry bigger than our buffer, we'll never write those and it would be bad if we tried to read one. Also improve the diagnostic messages. Signed-off-by: Kent Overstreet <kmo@daterainc.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
- 26 Aug, 2014 33 commits
-
-
Jiri Slaby authored
-
Ales Novak authored
commit ee1d9014 upstream. In __rtc_read_alarm(), if the alarm time retrieved by rtc_read_alarm_internal() from the device contains invalid values (e.g. month=2,mday=31) and the year not set (=-1), the initialization will loop infinitely because the year-fixing loop expects the time being invalid due to leap year. Fix reduces the loop to the leap years and adds final validity check. Signed-off-by: Ales Novak <alnovak@suse.cz> Acked-by: Alessandro Zummo <a.zummo@towertech.it> Reported-by: Jiri Bohac <jbohac@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Jan Beulich authored
commit 6e85bab6 upstream. In particular seeing zero in eft->month is problematic, as it results in -1 (converted to unsigned int, i.e. yielding 0xffffffff) getting passed to rtc_year_days(), where the value gets used as an array index (normally resulting in a crash). This was observed with the driver enabled on x86 on some Fujitsu system (with possibly not up to date firmware, but anyway). Perhaps efi_read_alarm() should not fail if neither enabled nor pending are set, but the returned time is invalid? Signed-off-by: Jan Beulich <jbeulich@suse.com> Reported-by: Raymund Will <rw@suse.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Jingoo Han <jg1.han@samsung.com> Acked-by: Lee, Chun-Yi <jlee@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Lee, Chun-Yi authored
commit 809d9627 upstream. Compared source code of rtc-lib.c::rtc_year_days() with efirtc.c::rtc_year_days(), found the code in rtc-efi decreases value of day twice when it computing year days. rtc-lib.c::rtc_year_days() has already decrease days and return the year days from 0 to 365. Signed-off-by: Lee, Chun-Yi <jlee@suse.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Vitaliy Kulikov authored
commit d009f3de upstream. Adds linear EQ filtering for integrated speaker protection Signed-off-by: Vitaliy Kulikov <vitaliy.kulikov@idt.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Benjamin Tisssoires authored
commit 42c22dbf upstream. This fix (not very clean though) should fix the long time USB3 issue that was spotted last year. The rational has been given by Hans de Goede: ---- I think the most likely cause for this is a firmware bug in the unifying receiver, likely a race condition. The most prominent difference between having a USB-2 device plugged into an EHCI (so USB-2 only) port versus an XHCI port will be inter packet timing. Specifically if you send packets (ie hid reports) one at a time, then with the EHCI controller their will be a significant pause between them, where with XHCI they will be very close together in time. The reason for this is the difference in EHCI / XHCI controller OS <-> driver interfaces. For non periodic endpoints (control, bulk) the EHCI uses a circular linked-list of commands in dma-memory, which it follows to execute commands, if the list is empty, it will go into an idle state and re-check periodically. The XHCI uses a ring of commands per endpoint, and if the OS places anything new on the ring it will do an ioport write, waking up the XHCI making it send the new packet immediately. For periodic transfers (isoc, interrupt) the delay between packets when sending one at a time (rather then queuing them up) will be even larger, because they need to be inserted into the EHCI schedule 2 ms in the future so the OS driver can be sure that the EHCI driver does not try to start executing the time slot in question before the insertion has completed. So a possible fix may be to insert a delay between packets being send to the receiver. ---- I tested this on a buggy Haswell USB 3.0 motherboard, and I always get the notification after adding the msleep. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Jiri Kosina authored
commit 8c947e20 upstream. Acer Aspire needs to be added to nomux blacklist, otherwise the touchpad misbehaves rather randomly. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Laurent Dufour authored
commit 761ce533 upstream. Numerical values stored in the device tree are encoded in Big Endian and should be byte swapped when running in Little Endian. The RPA hotplug module should convert those values as well. Note that in rpaphp_get_drc_props(), the comparison between indexes[i+1] and *index is done using the BE values (whatever is the current endianess). This doesn't matter since we are checking for equality here. This way only the returned value is byte swapped. RPA also made RTAS calls which implies BE values to be used. According to the patch done in RTAS (http://patchwork.ozlabs.org/patch/336865), no additional conversion is required in RPA. Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Ying Xue authored
commit 5c0a0fc8 upstream. tipc_msg_build() calls skb_copy_to_linear_data_offset() to copy data from user space to kernel space. However, the latter function does in its turn call memcpy() to perform the actual copying. This poses an obvious security and robustness risk, since memcpy() never makes any validity check on the pointer it is copying from. To correct this, we the replace the offending function call with a call to memcpy_fromiovecend(), which uses copy_from_user() to perform the copying. Signed-off-by: Ying Xue <ying.xue@windriver.com> Reviewed-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Nithin Sujir authored
commit 68273712 upstream. This patch adds support for 57764, 57765, 57787, 57782 and 57786 devices. Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Maurizio Lombardi authored
commit fdbcbcab upstream. In case of error, the bnx2fc_allocate_hash_table() didn't free all the memory it allocated. Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Acked-by: Eddie Wai <eddie.wai@broadcom.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Yuval Mintz authored
commit bd8e012b upstream. Since commit 3fb43eb2 ("bnx2x: Change to D3hot only on removal") nvram is accessible whenever the driver is loaded - Thus it is possible to test it during self-test even if the interface is down Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com> Signed-off-by: Ariel Elior <ariele@broadcom.com> Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Dan Carpenter authored
commit e4514cbd upstream. The cpl_abort_req struct has several reserved members which need to be cleared to avoid disclosing kernel information. I have added a memset() so now it matches the cxgb4 version of this function. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
David Gibson authored
commit 4710b2ba upstream. netxen_process_lro() contains two bounds checks. One for the ring number against the number of rings, and one for the Rx buffer ID against the array of receive buffers. Both of these have off-by-one errors, using > instead of >=. The correct versions are used in netxen_process_rcv(), they're just wrong in netxen_process_lro(). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Russell King authored
commit 3e548079 upstream. The fallback to 32-bit DMA mask is rather odd: if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) && !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) { *using_dac = true; } else { err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32)); if (err) { err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); if (err) goto release_regions; } This means we only try and set the coherent DMA mask if we failed to set a 32-bit DMA mask, and only if both fail do we fail the driver. Adjust this so that if either setting fails, we fail the driver - and thereby end up properly setting both the DMA mask and the coherent DMA mask in the fallback case. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Wei Yongjun authored
commit de524681 upstream. Add the missing iounmap() before return from igbvf_probe() in the error handling case. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Tested-by: Sibai Li <Sibai.li@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Dan Carpenter authored
commit 3de9e65f upstream. If new_mtu is very large then "new_mtu + ETH_HLEN + ETH_FCS_LEN" can wrap and the check on the next line can underflow. This is one of those bugs which can be triggered by the user if you have namespaces configured. Also since this is something the user can trigger then we don't want to have dev_err() message. This is a static checker fix and I'm not sure what the impact is. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Tested-by: Sibai Li Sibai.li@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Russell King authored
commit c21b8ebc upstream. The fallback to 32-bit DMA mask is rather odd: err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)); if (!err) { err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64)); if (!err) pci_using_dac = 1; } else { err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32)); if (err) { err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); if (err) { dev_err(&pdev->dev, "No usable DMA " "configuration, aborting\n"); goto err_dma; } } } This means we only set the coherent DMA mask in the fallback path if the DMA mask set failed, which is silly. This fixes it to set the coherent DMA mask only if dma_set_mask() succeeded, and to error out if either fails. Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Akeem G Abodunrin authored
commit 42ce4126 upstream. This patch fixes Wake on LAN being reported as supported on some Ethernet ports, in contrary to Hardware capability. Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Fujinaka, Todd authored
commit a71fc313 upstream. Don't let ethtool try to write to iNVM in i210/i211. This fixes an issue seen by Marek Vasut. Reported-by: Marek Vasut <marex@denx.de> Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Stefan Assmann authored
commit 781798a1 upstream. commit fa44f2f1 broke reloading of igb, when VFs are assigned to a guest, in several ways. 1. on module load adapter->vf_data does not get properly allocated, resulting in a null pointer exception when accessing adapter->vf_data in igb_reset() on module reload. modprobe -r igb ; modprobe igb max_vfs=7 [ 215.215837] igb 0000:01:00.1: removed PHC on eth1 [ 216.932072] igb 0000:01:00.1: IOV Disabled [ 216.937038] igb 0000:01:00.0: removed PHC on eth0 [ 217.127032] igb 0000:01:00.0: Cannot deallocate SR-IOV virtual functions while they are assigned - VFs will not be deallocated [ 217.146178] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.0.5-k [ 217.154050] igb: Copyright (c) 2007-2013 Intel Corporation. [ 217.160688] igb 0000:01:00.0: Enabling SR-IOV VFs using the module parameter is deprecated - please use the pci sysfs interface. [ 217.173703] igb 0000:01:00.0: irq 103 for MSI/MSI-X [ 217.179227] igb 0000:01:00.0: irq 104 for MSI/MSI-X [ 217.184735] igb 0000:01:00.0: irq 105 for MSI/MSI-X [ 217.220082] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 [ 217.228846] IP: [<ffffffffa007c5e5>] igb_reset+0xc5/0x4b0 [igb] [ 217.235472] PGD 3607ec067 PUD 36170b067 PMD 0 [ 217.240461] Oops: 0002 [#1] SMP [ 217.244085] Modules linked in: igb(+) igbvf mptsas mptscsih mptbase scsi_transport_sas [last unloaded: igb] [ 217.255040] CPU: 4 PID: 4833 Comm: modprobe Not tainted 3.11.0+ #46 [...] [ 217.390007] [<ffffffffa007fab2>] igb_probe+0x892/0xfd0 [igb] [ 217.396422] [<ffffffff81470b3e>] local_pci_probe+0x1e/0x40 [ 217.402641] [<ffffffff81472029>] pci_device_probe+0xf9/0x110 [...] 2. A follow up issue, pci_enable_sriov() should only be called if no VFs were still allocated on module unload. Otherwise pci_enable_sriov() gets called multiple times in a row rendering the NIC unusable until reset. 3. simply calling igb_enable_sriov() in igb_probe_vfs() is not enough as the interrupts need to be re-setup. Switching that to igb_pci_enable_sriov(). Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Tested-by: Sibai Li <Sibai.li@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Carolyn Wyborny authored
commit d1c17d80 upstream. This patch calls code to set the master/slave mode for all m88 gen 2 PHY's. This patch also removes the call to this function for I210 devices only from the function that is not called by I210 devices. Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@gmail.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Fujinaka, Todd authored
commit a4e979a2 upstream. Add the ethtool offline tests for i354 devices. Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Russell King authored
commit dc4ff9bb upstream. The fallback to 32-bit DMA mask is rather odd: err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)); if (!err) { err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64)); if (!err) pci_using_dac = 1; } else { err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32)); if (err) { err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); if (err) { dev_err(&pdev->dev, "No usable DMA configuration, aborting\n"); goto err_dma; } } } This means we only set the coherent DMA mask in the fallback path if the DMA mask set failed, which is silly. This fixes it to set the coherent DMA mask only if dma_set_mask() succeeded, and to error out if either fails. Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Don Skidmore authored
commit c7bb417d upstream. Since we are already checking for read failure in check_link we don't need to do it here. Instead just make sure the watchdog task gets scheduled, if we are up, and it can be done there. This will better follow igbvf method of handling a mailbox event and message timeout. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Russell King authored
commit 53567aa4 upstream. The fallback to 32-bit DMA mask is rather odd: if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) && !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) { pci_using_dac = 1; } else { err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32)); if (err) { err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); if (err) { dev_err(&pdev->dev, "No usable DMA " "configuration, aborting\n"); goto err_dma; } } pci_using_dac = 0; } This means we only set the coherent DMA mask in the fallback path if the DMA mask set failed, which is silly. This fixes it to set the coherent DMA mask only if dma_set_mask() succeeded, and to error out if either fails. Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Emil Tantilov authored
commit cf78959c upstream. This patch resolves an issue where the MTA table can be cleared when the interface is reset while in promisc mode. As result IPv6 traffic between VFs will be interrupted. This patch makes the update of the MTA table unconditional to avoid the inconsistent clearing on reset. Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Jacob Keller authored
commit 27d9ce4f upstream. ixgbe_napi_disable_all calls napi_disable on each queue, however the busy polling code introduced a local_bh_disable()d context around the napi_disable. The original author did not realize that napi_disable might sleep, which would cause a sleep while atomic BUG. In addition, on a single processor system, the ixgbe_qv_lock_napi loop shouldn't have to mdelay. This patch adds an ixgbe_qv_disable along with a new IXGBE_QV_STATE_DISABLED bit, which it uses to indicate to the poll and napi routines that the q_vector has been disabled. Now the ixgbe_napi_disable_all function will wait until all pending work has been finished and prevent any future work from being started. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Cc: Eliezer Tamir <eliezer.tamir@linux.intel.com> Cc: Alexander Duyck <alexander.duyck@intel.com> Cc: Hyong-Youb Kim <hykim@myri.com> Cc: Amir Vadai <amirv@mellanox.com> Cc: Dmitry Kravkov <dmitry@broadcom.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Emil Tantilov authored
commit 2e010381 upstream. This patch resolves an issue where the logic used to detect changes in rx-usecs was incorrect and was masked by the call to ixgbe_update_rsc(). Setting rx-usecs between 0,2-9 and 1,10 and up requires a reset to allow ixgbe_configure_tx_ring() to set the correct value for TXDCTL.WTHRESH in order to avoid Tx hangs with BQL enabled. Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Russell King authored
commit f5f2eda8 upstream. The fallback to 32-bit DMA mask is rather odd: if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) && !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) { pci_using_dac = 1; } else { err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32)); if (err) { err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); if (err) { dev_err(&pdev->dev, "No usable DMA configuration, aborting\n"); goto err_dma; } } pci_using_dac = 0; } This means we only set the coherent DMA mask in the fallback path if the DMA mask set failed, which is silly. This fixes it to set the coherent DMA mask only if dma_set_mask() succeeded, and to error out if either fails. Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Vladimir Davydov authored
commit 74a1b1ea upstream. On e1000_down(), we should ensure every asynchronous work is canceled before proceeding. Since the watchdog_task can schedule other works apart from itself, it should be stopped first, but currently it is stopped after the reset_task. This can result in the following race leading to the reset_task running after the module unload: e1000_down_and_stop(): e1000_watchdog(): ---------------------- ----------------- cancel_work_sync(reset_task) schedule_work(reset_task) cancel_delayed_work_sync(watchdog_task) The patch moves cancel_delayed_work_sync(watchdog_task) at the beginning of e1000_down_and_stop() thus ensuring the race is impossible. Cc: Tushar Dave <tushar.n.dave@intel.com> Cc: Patrick McHardy <kaber@trash.net> Signed-off-by: Vladimir Davydov <vdavydov@parallels.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
yzhu1 authored
commit 6a7d64e3 upstream. This change is based on a similar change made to e1000e support in commit bb9e44d0 ("e1000e: prevent oops when adapter is being closed and reset simultaneously"). The same issue has also been observed on the older e1000 cards. Here, we have increased the RESET_COUNT value to 50 because there are too many accesses to e1000 nic on stress tests to e1000 nic, it is not enough to set RESET_COUT 25. Experimentation has shown that it is enough to set RESET_COUNT 50. Signed-off-by: yzhu1 <yanjun.zhu@windriver.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-
Hong Zhiguo authored
commit 49a45a06 upstream. tx_ring and adapter->tx_ring are already of type "struct e1000_tx_ring *" Signed-off-by: Hong Zhiguo <zhiguohong@tencent.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
-