- 03 Mar, 2013 18 commits
-
-
Adam Thomas authored
commit 8afd500c upstream. The last orphan in the dnext list has its dnext set to NULL. Because of that, ubifs_delete_orphan assumes that it is not on the dnext list and frees it immediately instead ignoring it as a second delete. The orphan is later freed again by erase_deleted. This change adds an explicit flag to ubifs_orphan indicating whether it is pending delete. Signed-off-by:
Adam Thomas <adamthomas1111@gmail.com> Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Adam Thomas authored
commit 2928f0d0 upstream. The last orphan in the cnext list has its cnext set to NULL. Because of that, ubifs_delete_orphan assumes that it is not on the cnext list and frees it immediately instead of adding it to the dnext list. The freed orphan is later modified by write_orph_node. This can cause various inconsistencies including directory entries that cannot be removed and this error: UBIFS error (pid 20685): layout_cnodes: LPT out of space at LEB 14:129009 needing 17, done_ltab 1, done_lsave 1 This is a regression introduced by "7074e5eb UBIFS: remove invalid reference to list iterator variable". This change adds an explicit flag to ubifs_orphan indicating whether it is pending commit. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Larry Finger authored
commit 63a02ce1 upstream. On unload, b43 produces a lockdep warning that can be summarized in the following way: ====================================================== [ INFO: possible circular locking dependency detected ] 3.8.0-wl+ #117 Not tainted ------------------------------------------------------- modprobe/5557 is trying to acquire lock: ((&wl->firmware_load)){+.+.+.}, at: [<ffffffff81062160>] flush_work+0x0/0x2a0 but task is already holding lock: (rtnl_mutex){+.+.+.}, at: [<ffffffff813bd7d2>] rtnl_lock+0x12/0x20 which lock already depends on the new lock. [ INFO: possible circular locking dependency detected ] ====================================================== The full output is available at http://lkml.indiana.edu/hypermail/linux/kernel/1302.3/00060.html. To summarize, commit 6b6fa586 added a 'cancel_work_sync(&wl->firmware_load)' call in the wrong place. The fix is to move the cancel_work_sync() call to b43_bcma_remove() and b43_ssb_remove(). Thanks to Johannes Berg and Michael Buesch for help in diagnosing the log output. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Felipe Balbi authored
commit 1a947746 upstream. First of all, that 28 value makes no sense as HIRD threshold is a 4-bit value, second of all it's causing issues for OMAP5. Using 12 because commit cbc725b3 (usb: dwc3: keep default hird threshold value as 4b1100) had the intention of setting the maximum allowed value of 0xc. Also, original code has been wrong forever, so this should be backported as far back as possible. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Pratyush Anand authored
commit 915e202a upstream. When we reach to link trb, we just need to increase free_slot and then calculate TRB. Return is not correct, as it will cause wrong TRB DMA address to fetch in case of update transfer. Signed-off-by:
Pratyush Anand <pratyush.anand@st.com> Signed-off-by:
-
Pratyush Anand authored
commit cdc359dd upstream. There were still some corner cases where isoc transfer was not able to restart, specially when missed isoc does not happen , and in fact gadget does not queue any new request during giveback. Cleanup function calls giveback first, which provides a way to queue another request to gadget. But gadget did not had any data. So , it did not call ep_queue. To twist it further, gadget did not queue till cleanup for last queued TRB is called. If we ever reach this scenario, we must call END TRANSFER, so that we receive a new xfernotready with information about current microframe number. Also insure that there is no request submitted to core when issuing END TRANSFER. Signed-off-by:
-
Pratyush Anand authored
commit 7efea86c upstream. There are two reasons to generate missed isoc. 1. when the host does not poll for all the data. 2. because of application-side delays that prevent all the data from being transferred in programmed microframe. Current code was able to handle first case only. This patch handles scenario 2 as well.Scenario 2 sometime may occur with complex gadget application, however it can be easily reproduced for testing purpose as follows: a. use isoc binterval as 1 in f_sourcesink. b. use pattern=0 c. introduce a delay of 150us deliberately in source_sink_complete, so that after few frames it lands into scenario 2. d. now run testusb 16 (isoc in test). You will notice that if this patch is not applied then isoc transfer is not able to recover after first missed. Current patch's approach is as under: If missed isoc occurs and there is no request queued then issue END TRANSFER, so that core generates next xfernotready and we will issue a fresh START TRANSFER. If there are still queued request then wait, do not issue either END or UPDATE TRANSFER, just attach next request in request_list during giveback. If any future queued request is successfully transferred then we will issue UPDATE TRANSFER for all request in the request_list. Signed-off-by:
-
Pratyush Anand authored
commit 2b758350 upstream. Synopsys says: The HIRD Threshold field must be set to ‘0’ when the device core is operating in super speed mode. This patch implements above statement. Acked-by:
Paul Zimmerman <paulz@synopsys.com> Signed-off-by:
-
Theodore Ts'o authored
commit c3ad83d9 upstream. Otherwise, ext4 file systems with the quota featured enable will get a very confusing "No such process" error message if the quota code is built as a module and the quota_v2 module has not been loaded. Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Reviewed-by:
Carlos Maiolino <cmaiolino@redhat.com> Acked-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Bart Van Assche authored
commit 2ce19e72 upstream. If an SRP target is no longer reachable and srp_reset_host() fails to reconnect then ib_srp will invoke scsi_remove_host(). That function will invoke __scsi_remove_device() for each LUN. And that last function will change the device state from SDEV_TRANSPORT_OFFLINE into SDEV_CANCEL. Certain user space software, e.g. older versions of multipathd, continue queueing I/O to SCSI devices that are in the SDEV_CANCEL state. If these I/O requests are submitted as SG_IO that means that the REQ_PREEMPT flag will be set and hence that these requests will be passed to srp_queuecommand(). These requests will time out. If new requests are queued fast enough from user space these active requests will prevent __scsi_remove_device() to finish. Avoid this by failing I/O requests in the SDEV_CANCEL state if the transport is offline. Introduce a new variable to keep track of the transport state instead of failing requests if (!target->connected || target->qp_in_error), so that the SCSI error handler has a chance to retry commands after a transport layer failure occurred. Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Bart Van Assche authored
commit c7c4e7ff upstream. If a SCSI command times out it is passed to the SCSI error handler. The SCSI error handler will try to abort the commands that timed out. If aborting fails, a device reset will be attempted. If the device reset also fails a host reset will be attempted. If the host reset also fails the whole procedure will be repeated. srp_abort() and srp_reset_device() fail for a QP in the error state. srp_reset_host() fails after host removal has started. Hence if the SCSI error handler gets invoked after host removal has started and with the QP in the error state an endless loop will be triggered. Modify the SCSI error handling functions in ib_srp as follows: - Abort SCSI commands properly even if the QP is in the error state. - Make srp_reset_host() reset SCSI requests even after host removal has already started or if reconnecting fails. Signed-off-by:
David Dillow <dave@thedillows.org> Signed-off-by:
-
Bart Van Assche authored
commit 3780d1f0 upstream. Do not send a task management function if sending will fail anyway because either there is no RDMA/RC connection or the QP is in the error state. Signed-off-by:
-
Bart Van Assche authored
commit e1b2f13a upstream. Remove an assignment that incorrectly overwrites the connection state update by srp_connect_target(). Signed-off-by:
-
Florian Zeitz authored
commit b56ddbe5 upstream. This expands the regression fix from d2821599. The firmware also needs to be loaded when it was already cached. Signed-off-by:
Florian Zeitz <florob@babelmonkeys.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Mihail Zenkov authored
commit d2821599 upstream. This patch fix regression in emu1010 firmware loading after http://git.alsa-project.org/?p=alsa-kprivate.git;a=commitdiff;h=b209c4dfcd960ab176d4746ab7dc442a3edb4575 I just revert small part of this commit. Tested on emu1212m pci. Signed-off-by:
Mihail Zenkov <mihail.zenkov@gmail.com> Signed-off-by:
-
David Henningsson authored
commit 30efd8de upstream. Just as for analog codecs, a jack that isn't suitable for detection (in this case, NO_PRESENCE was set) should be a phantom Jack instead of a normal one. Thanks to Raymond Yau for spotting. BugLink: https://bugs.launchpad.net/bugs/961286 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=903869Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Takashi Iwai authored
commit aacfddfd upstream. Along with a clean up commit [e9f66d9b: ALSA: pci: clean up using module_pci_driver()], bt87x driver lost the functionality of load_all parameter. This patch does a partial revert of the commit only for bt87x.c to recover it. Reported-by:
Clemens Ladisch <cladisch@googlemail.com> Signed-off-by:
-
Linus Torvalds authored
commit 09884964 upstream. The stack vma is designed to grow automatically (marked with VM_GROWSUP or VM_GROWSDOWN depending on architecture) when an access is made beyond the existing boundary. However, particularly if you have not limited your stack at all ("ulimit -s unlimited"), this can cause the stack to grow even if the access was really just one past *another* segment. And that's wrong, especially since we first grow the segment, but then immediately later enforce the stack guard page on the last page of the segment. So _despite_ first growing the stack segment as a result of the access, the kernel will then make the access cause a SIGSEGV anyway! So do the same logic as the guard page check does, and consider an access to within one page of the next segment to be a bad access, rather than growing the stack to abut the next segment. Reported-and-tested-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
- 28 Feb, 2013 22 commits
-
-
Greg Kroah-Hartman authored
-
Ben Skeggs authored
commit ac8cc241 upstream. A single U encoder table can match multiple DCB entries, whereas the reverse is not true and can lead to us not matching a DCB entry at all, and fail to initialise some encoders. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Ben Skeggs authored
commit 8e992c8d upstream. Matches format used by a couple of other vbios tables, useful to have laying around already calculated. Signed-off-by:
-
Ben Skeggs authored
commit f3ed1048 upstream. Signed-off-by:
-
Fabio Baltieri authored
commit 99d17cfa upstream. This patch converts the module to use clk_prepare_enable and clk_disable_unprepare variants as required by common clock framework. Without this the system crash during probe function. Signed-off-by:
Fabio Baltieri <fabio.baltieri@linaro.org> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Ming Lei authored
commit 25736e0c upstream. This patch let glue driver return -EPROBE_DEFER if the transceiver is not readly, so we can support defer probe on musb to fix the below error on 3.7-rc5 if transceiver drivers are built as module: [ 19.052490] unable to find transceiver of type USB2 PHY [ 19.072052] HS USB OTG: no transceiver configured [ 19.076995] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -19 [ 19.089355] musb-hdrc: probe of musb-hdrc.0.auto rejects match -19 [ 19.096771] driver: 'musb-omap2430': driver_bound: bound to device 'musb-omap2430' [ 19.105194] bus: 'platform': really_probe: bound device musb-omap2430 to driver musb-omap2430 [ 19.174407] bus: 'platform': add driver twl4030_usb [ 19.179656] bus: 'platform': driver_probe_device: matched device twl4030_usb with driver twl4030_usb [ 19.202270] bus: 'platform': really_probe: probing driver twl4030_usb with device twl4030_usb [ 19.214172] twl4030_usb twl4030_usb: HW_CONDITIONS 0xc0/192; link 3 [ 19.239624] musb-omap2430 musb-omap2430: musb core is not yet ready [ 19.246765] twl4030_usb twl4030_usb: Initialized TWL4030 USB module [ 19.254516] driver: 'twl4030_usb': driver_bound: bound to device 'twl4030_usb' [ 19.263580] bus: 'platform': really_probe: bound device twl4030_usb to driver twl4030_usb Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
-
Ming Lei authored
commit 681d1e87 upstream. In the fail1~fail5 failure path, pm_runtime_disable() should be called to avoid 'Unbalanced pm_runtime_enable' error in next probe() which may be triggered by defer probe or next 'modprobe musb_hdrc'. Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Signed-off-by:
-
Josh Boyer authored
commit 18e03310 upstream. The current entry in unusual_cypress.h for the Super TOP SATA bridge devices seems to be causing corruption on newer revisions of this device. This has been reported in Arch Linux and Fedora. The original patch was tested on devices with bcdDevice of 1.60, whereas the newer devices report bcdDevice as 2.20. Limit the UNUSUAL_DEV entry to devices less than 2.20. This fixes https://bugzilla.redhat.com/show_bug.cgi?id=909591 The Arch Forum post on this is here: https://bbs.archlinux.org/viewtopic.php?id=152011Reported-by:
Carsten S. <carsteniq@yahoo.com> Tested-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
fangxiaozhi authored
commit cd060956 upstream. 1. The idProduct is little endian, so make sure its value to be compatible with the current CPU. Make no break on big endian processors. Signed-off-by:
fangxiaozhi <huananhu@huawei.com> Signed-off-by:
-
Roger Quadros authored
commit 04753523 upstream. The module alias should be "ehci-omap" and not "omap-ehci" to match the platform device name. The omap-ehci module should now autoload correctly. Signed-off-by:
Roger Quadros <rogerq@ti.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Bjørn Mork authored
commit 1f3f6877 upstream. The USB device descriptor of one identity presented by a few Huawei morphing devices have serial functions with class codes 02/02/ff, indicating CDC ACM with a vendor specific protocol. This combination is often used for MSFT RNDIS functions, and the CDC ACM class driver will therefore ignore such functions. The CDC ACM class driver cannot support functions with only 2 endpoints. The underlying serial functions of these modems are also believed to be the same as for alternate device identities already supported by the option driver. Letting the same driver handle these functions independently of the current identity ensures consistent handling and user experience. There is no need to blacklist these devices in the rndis_host driver. Huawei serial functions will either have only 2 endpoints or a CDC ACM functional descriptor with bmCapabilities != 0, making them correctly ignored as "non RNDIS" by that driver. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Bjørn Mork authored
commit cd565279 upstream. Interface layout: 00 CD-ROM 01 debug COM port 02 AP control port 03 modem 04 usb-ethernet Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0408 ProdID=ea42 Rev= 0.00 S: Manufacturer=Qualcomm, Incorporated S: Product=Qualcomm CDMA Technologies MSM S: SerialNumber=353568051xxxxxx C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=86(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms Signed-off-by:
-
Bjørn Mork authored
commit f8f0302b upstream. Adding three currently unsupported modems based on information from .inf driver files: Diag VID_1BBB&PID_0052&MI_00 AGPS VID_1BBB&PID_0052&MI_01 VOICE VID_1BBB&PID_0052&MI_02 AT VID_1BBB&PID_0052&MI_03 Modem VID_1BBB&PID_0052&MI_05 wwan VID_1BBB&PID_0052&MI_06 Diag VID_1BBB&PID_00B6&MI_00 AT VID_1BBB&PID_00B6&MI_01 Modem VID_1BBB&PID_00B6&MI_02 wwan VID_1BBB&PID_00B6&MI_03 Diag VID_1BBB&PID_00B7&MI_00 AGPS VID_1BBB&PID_00B7&MI_01 VOICE VID_1BBB&PID_00B7&MI_02 AT VID_1BBB&PID_00B7&MI_03 Modem VID_1BBB&PID_00B7&MI_04 wwan VID_1BBB&PID_00B7&MI_05 Updating the blacklist info for the X060S_X200 and X220_X500D, reserving interfaces for a wwan driver, based on wwan VID_1BBB&PID_0000&MI_04 wwan VID_1BBB&PID_0017&MI_06 Signed-off-by:
-
Maciej Sosnowski authored
commit c419fcfd upstream. When providers get blocked unregister_dca_providers() is called ending up with dca_providers and dca_domain lists emptied. Dca should be prevented from trying to unregister any provider if dca_domain list is found empty. Reported-by:
Jiang Liu <jiang.liu@huawei.com> Tested-by:
Gaohuai Han <hangaohuai@huawei.com> Signed-off-by:
Maciej Sosnowski <maciej.sosnowski@intel.com> Signed-off-by:
Dan Williams <djbw@fb.com> Signed-off-by:
-
Guennadi Liakhovetski authored
commit 7c1119bd upstream. If dmaengine driver's .device_alloc_chan_resources() method returns -ENODEV, dma_request_channel() will decide, that the driver has been removed and will remove the device from its list. To prevent this use ENXIO if a slave lookup fails. Reported-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Vinod Koul <vinod.koul@linux.intel.com> Signed-off-by:
-
Magnus Damm authored
commit c7886b18 upstream. Adjust the gpio-em.c driver to reconsider the pdata->irq_base variable. Non-DT board code like for instance board-kzm9d.c needs to operate of a static IRQ range for platform devices. So this patch is updating the code to make use of the function irq_domain_add_simple() instead of irq_domain_add_linear(). Fixes a EMEV2 / KZM9D runtime error caused by the following commit: 7385500a gpio/em: convert to linear IRQ domain Signed-off-by:
Magnus Damm <damm@opensource.se> Tested-by:
Simon Horman <horms+renesas@verge.net.au> Reported-by:
-
Roger Quadros authored
commit 428525f9 upstream. This driver does not request any gpios so don't free them. Fixes L3 bus error on multiple modprobe/rmmod of ehci_hcd with ehci-omap in use. Without this patch, EHCI will break on repeated insmod/rmmod of ehci_hcd for all OMAP2+ platforms that use EHCI and set 'phy_reset = true' in usbhs_omap_board_data. i.e. board-3430sdp.c: .phy_reset = true, board-3630sdp.c: .phy_reset = true, board-am3517crane.c: .phy_reset = true, board-am3517evm.c: .phy_reset = true, board-cm-t3517.c: .phy_reset = true, board-cm-t35.c: .phy_reset = true, board-devkit8000.c: .phy_reset = true, board-igep0020.c: .phy_reset = true, board-igep0020.c: .phy_reset = true, board-omap3beagle.c: .phy_reset = true, board-omap3evm.c: .phy_reset = true, board-omap3pandora.c: .phy_reset = true, board-omap3stalker.c: .phy_reset = true, board-omap3touchbook.c: .phy_reset = true, board-omap4panda.c: .phy_reset = false, board-overo.c: .phy_reset = true, board-zoom.c: .phy_reset = true, Signed-off-by:
-
Johannes Berg authored
Commit 5b36ebd8 upstream. In some cases when disconnecting after (or during?) CSA the queues might not recover, and then the only way to recover is reloading the module. Fix this by always unblocking the queue CSA reason when disconnecting. Reported-by:
Jan-Michael Brummer <jan.brummer@tabos.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Cong Wang authored
[ Upstream commit da8c8724 ] There are two places to call vlan_set_encap_proto(): vlan_untag() and __pop_vlan_tci(). vlan_untag() assumes skb->data points after mac addr, otherwise the following code vhdr = (struct vlan_hdr *) skb->data; vlan_tci = ntohs(vhdr->h_vlan_TCI); __vlan_hwaccel_put_tag(skb, vlan_tci); skb_pull_rcsum(skb, VLAN_HLEN); won't be correct. But __pop_vlan_tci() assumes points _before_ mac addr. In vlan_set_encap_proto(), it looks for some magic L2 value after mac addr: rawp = skb->data; if (*(unsigned short *) rawp == 0xFFFF) ... Therefore __pop_vlan_tci() is obviously wrong. A quick fix is avoiding using skb->data in vlan_set_encap_proto(), use 'vhdr+1' is always correct in both cases. Signed-off-by:
Cong Wang <amwang@redhat.com> Cc: David S. Miller <davem@davemloft.net> Cc: Jesse Gross <jesse@nicira.com> Acked-by:
Jesse Gross <jesse@nicira.com> Signed-off-by:
-
Mathias Krause authored
[ Upstream commit 6e601a53 ] Userland can send a netlink message requesting SOCK_DIAG_BY_FAMILY with a family greater or equal then AF_MAX -- the array size of sock_diag_handlers[]. The current code does not test for this condition therefore is vulnerable to an out-of-bound access opening doors for a privilege escalation. Signed-off-by:
Mathias Krause <minipli@googlemail.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Kleber Sacilotto de Souza authored
[ Upstream commit 37706996 ] The mlx4_en driver allocates the number of objects for the CPU affinity reverse-map based on the number of rx rings of the device. However, mlx4_assign_eq() calls irq_cpu_rmap_add() as many times as IRQ's are assigned to EQ's, which can be as large as mlx4_dev->caps.comp_pool. If caps.comp_pool is larger than rx_ring_num we will eventually hit the BUG_ON() in cpu_rmap_add(). Fix this problem by allocating space for the maximum number of CPU affinity reverse-map objects we might want to add. Signed-off-by:
Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com> Acked-by:
Amir Vadai <amirv@mellanox.com> Signed-off-by:
-
Kleber Sacilotto de Souza authored
[ Upstream commit 427a9625 ] The memory to hold the network device tx_cq is not being allocated with the correct size in mlx4_en_init_netdev(). It should use MAX_TX_RINGS instead of MAX_RX_RINGS. This can cause problems if the number of tx rings being used is greater than MAX_RX_RINGS. Signed-off-by:
-
