- 16 Mar, 2017 40 commits
-
-
Takashi Iwai authored
commit 4763601a upstream. The function returns -EINVAL even if it builds the stream properly. The bogus error code sneaked in during the code refactoring, but it wasn't noticed until now since the returned error code itself is ignored in anyway. Kill it here, but there is no behavior change by this patch, obviously. Fixes: e5779998 ('ALSA: usb-audio: refactor code') Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Boris Ostrovsky authored
commit 30faaafd upstream. Commit 9c17d965 ("xen/gntdev: Grant maps should not be subject to NUMA balancing") set VM_IO flag to prevent grant maps from being subjected to NUMA balancing. It was discovered recently that this flag causes get_user_pages() to always fail with -EFAULT. check_vma_flags __get_user_pages __get_user_pages_locked __get_user_pages_unlocked get_user_pages_fast iov_iter_get_pages dio_refill_pages do_direct_IO do_blockdev_direct_IO do_blockdev_direct_IO ext4_direct_IO_read generic_file_read_iter aio_run_iocb (which can happen if guest's vdisk has direct-io-safe option). To avoid this let's use VM_MIXEDMAP flag instead --- it prevents NUMA balancing just as VM_IO does and has no effect on check_vma_flags(). Reported-by:
Olaf Hering <olaf@aepfle.de> Suggested-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
-
Nicolai Stange authored
commit 05e6ea26 upstream. The struct file_operations instance serving the f2fs/status debugfs file lacks an initialization of its ->owner. This means that although that file might have been opened, the f2fs module can still get removed. Any further operation on that opened file, releasing included, will cause accesses to unmapped memory. Indeed, Mike Marshall reported the following: BUG: unable to handle kernel paging request at ffffffffa0307430 IP: [<ffffffff8132a224>] full_proxy_release+0x24/0x90 <...> Call Trace: [] __fput+0xdf/0x1d0 [] ____fput+0xe/0x10 [] task_work_run+0x8e/0xc0 [] do_exit+0x2ae/0xae0 [] ? __audit_syscall_entry+0xae/0x100 [] ? syscall_trace_enter+0x1ca/0x310 [] do_group_exit+0x44/0xc0 [] SyS_exit_group+0x14/0x20 [] do_syscall_64+0x61/0x150 [] entry_SYSCALL64_slow_path+0x25/0x25 <...> ---[ end trace f22ae883fa3ea6b8 ]--- Fixing recursive fault but reboot is needed! Fix this by initializing the f2fs/status file_operations' ->owner with THIS_MODULE. This will allow debugfs to grab a reference to the f2fs module upon any open on that file, thus preventing it from getting removed. Fixes: 902829aa ("f2fs: move proc files to debugfs") Reported-by:
Mike Marshall <hubcap@omnibond.com> Reported-by:
Martin Brandenburg <martin@omnibond.com> Signed-off-by:
Nicolai Stange <nicstange@gmail.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Kirtika Ruchandani authored
commit daaadbf0 upstream. Commit 2cbbb579 ("regmap: Add the LZO cache support") introduced 'blksize' in regcache_lzo_read() and regcache_lzo_write(), that is set but not used. Compiling with W=1 gives the following warnings, fix them. drivers/base/regmap/regcache-lzo.c: In function ‘regcache_lzo_read’: drivers/base/regmap/regcache-lzo.c:239:9: warning: variable ‘blksize’ set but not used [-Wunused-but-set-variable] size_t blksize, tmp_dst_len; ^ drivers/base/regmap/regcache-lzo.c: In function ‘regcache_lzo_write’: drivers/base/regmap/regcache-lzo.c:278:9: warning: variable ‘blksize’ set but not used [-Wunused-but-set-variable] size_t blksize, tmp_dst_len; ^ These are harmless warnings and are only being fixed to reduce the noise with W=1 in the kernel. Fixes: 2cbbb579 ("regmap: Add the LZO cache support") Cc: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
Kirtika Ruchandani <kirtika@chromium.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
commit d3d83ee2 upstream. A recent cleanup had the right idea to remove the initialization of the error variable, but missed the actual benefit of that, which is that we get warnings if there is a bug in it. Now we get a warning about a bug that was introduced by this cleanup: drivers/media/platform/davinci/vpfe_capture.c: In function 'vpfe_probe': drivers/media/platform/davinci/vpfe_capture.c:1992:9: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized] This adds the missing initialization that the warning is about, and another one that was preexisting and that we did not get a warning for. That second bug has existed since the driver was first added. Fixes: efb74461 ("[media] DaVinci-VPFE-Capture: Delete an unnecessary variable initialisation in vpfe_probe()") Fixes: 7da8a6cb ("V4L/DVB (12248): v4l: vpfe capture bridge driver for DM355 and DM6446") [mchehab@s-opensource.com: fix a merge conflict] Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Dan Carpenter authored
commit c4a407b9 upstream. We should unlock before returning this error code in vpfe_reqbufs(). Fixes: 622897da ("[media] davinci: vpfe: add v4l2 video driver support") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Ondrej Kozina authored
commit 265e9098 upstream. In crypt_set_key(), if a failure occurs while replacing the old key (e.g. tfm->setkey() fails) the key must not have DM_CRYPT_KEY_VALID flag set. Otherwise, the crypto layer would have an invalid key that still has DM_CRYPT_KEY_VALID flag set. Signed-off-by:
Ondrej Kozina <okozina@redhat.com> Reviewed-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Paul Mackerras authored
commit 0d808df0 upstream. When switching from/to a guest that has a transaction in progress, we need to save/restore the checkpointed register state. Although XER is part of the CPU state that gets checkpointed, the code that does this saving and restoring doesn't save/restore XER. This fixes it by saving and restoring the XER. To allow userspace to read/write the checkpointed XER value, we also add a new ONE_REG specifier. The visible effect of this bug is that the guest may see its XER value being corrupted when it uses transactions. Fixes: e4e38121 ("KVM: PPC: Book3S HV: Add transactional memory support") Fixes: 0a8eccef ("KVM: PPC: Book3S HV: Add missing code for transaction reclaim on guest exit") Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Reviewed-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
-
Theodore Ts'o authored
commit c48ae41b upstream. The commit "ext4: sanity check the block and cluster size at mount time" should prevent any problems, but in case the superblock is modified while the file system is mounted, add an extra safety check to make sure we won't overrun the allocated buffer. Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Theodore Ts'o authored
commit cd6bb35b upstream. Centralize the checks for inodes_per_block and be more strict to make sure the inodes_per_block_group can't end up being zero. Signed-off-by:
Andreas Dilger <adilger@dilger.ca> Signed-off-by:
-
Theodore Ts'o authored
commit 5aee0f8a upstream. Fix a large number of problems with how we handle mount options in the superblock. For one, if the string in the superblock is long enough that it is not null terminated, we could run off the end of the string and try to interpret superblocks fields as characters. It's unlikely this will cause a security problem, but it could result in an invalid parse. Also, parse_options is destructive to the string, so in some cases if there is a comma-separated string, it would be modified in the superblock. (Fortunately it only happens on file systems with a 1k block size.) Signed-off-by:
-
Johan Hovold authored
commit 015105b1 upstream. Make sure to drop the references taken by of_parse_phandle() and bus_find_device() before returning from am335x_get_phy_control(). Note that there is no guarantee that the devres-managed struct phy_control will be valid for the lifetime of the sibling phy device regardless of this change. Fixes: 3bb869c8 ("usb: phy: Add AM335x PHY driver") Acked-by:
Bin Liu <b-liu@ti.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Mathias Nyman authored
commit 37be6676 upstream. USB-3 does not have any link state that will avoid negotiating a connection with a plugged-in cable but will signal the host when the cable is unplugged. For USB-3 we used to first set the link to Disabled, then to RxDdetect to be able to detect cable connects or disconnects. But in RxDetect the connected device is detected again and eventually enabled. Instead set the link into U3 and disable remote wakeups for the device. This is what Windows does, and what Alan Stern suggested. Cc: Alan Stern <stern@rowland.harvard.edu> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Larry Finger authored
commit 8052d724 upstream. When there is a CRC error in the SPROM read from the device, the code attempts to handle a fallback SPROM. When this also fails, the driver returns zero rather than an error code. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Arnd Bergmann authored
commit af15769f upstream. gcc-7 notices that the condition in mvs_94xx_command_active looks suspicious: drivers/scsi/mvsas/mv_94xx.c: In function 'mvs_94xx_command_active': drivers/scsi/mvsas/mv_94xx.c:671:15: error: '<<' in boolean context, did you mean '<' ? [-Werror=int-in-bool-context] This was introduced when the mv_printk() statement got added, and leads to the condition being ignored. This is probably harmless. Changing '&&' to '&' makes the code look reasonable, as we check the command bit before setting and printing it. Fixes: a4632aae ("[SCSI] mvsas: Add new macros and functions") Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Saeed Mahameed authored
commit 6fa26208 upstream. Report the correct speed in the port attributes when using a 56Gbps ethernet link. Without this change the field is incorrectly set to 10. Fixes: a9c766bb ('IB/mlx4: Fix info returned when querying IBoE ports') Fixes: 2e96691c ('IB: Use central enum for speed instead of hard-coded values') Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
Yishai Hadas <yishaih@mellanox.com> Signed-off-by:
Daniel Jurgens <danielj@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Maor Gottlieb authored
commit 731e0415 upstream. Use INT_MAX since this is the max value the attribute can hold, though hardware capability is unlimited. Fixes: 225c7b1f ('IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters') Signed-off-by:
Maor Gottlieb <maorg@mellanox.com> Signed-off-by:
Mark Bloch <markb@mellanox.com> Reviewed-by:
Yuval Shaia <yuval.shaia@oracle.com> Signed-off-by:
-
Maor Gottlieb authored
commit af4295c1 upstream. Set traffic class within sl_tclass_flowlabel when create iboe AH. Without this the TOS value will be empty when running VLAN tagged traffic, because the TOS value is taken from the traffic class in the address handle attributes. Fixes: 9106c410 ('IB/mlx4: Fix SL to 802.1Q priority-bits mapping for IBoE') Signed-off-by:
-
Kamal Heib authored
commit 0b59970e upstream. Remove the warning print of "can't use of GFP_NOIO" to avoid prints in each QP creation when devices aren't supporting IB_QP_CREATE_USE_GFP_NOIO. This print become more annoying when the IPoIB interface is configured to work in connected mode. Fixes: 09b93088 ('IB: Add a QP creation flag to use GFP_NOIO allocations') Signed-off-by:
Kamal Heib <kamalh@mellanox.com> Signed-off-by:
-
Eli Cohen authored
commit acbda523 upstream. Wait before continuing unload till all pending mkey async creation requests are done. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
Eli Cohen <eli@mellanox.com> Signed-off-by:
-
Maor Gottlieb authored
commit 86695a65 upstream. We put INT_MAX since this is the max value that can be held. Though there is no hardware limitation, this is practically a large enough number so we can use it. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
-
Mark Bloch authored
commit 8ecc7985 upstream. When we create flow steering rule, we need to save the related QP in the ib_flow struct. this QP is used in destroy flow. Move the QP assignment from ib_uverbs_ex_create_flow into ib_create_flow, this would allow both kernel and userspace consumers to use it. This bug wasn't seen in the wild because there are no kernel consumers currently in the kernel. Fixes: 319a441d ("IB/core: Add receive flow steering support") Signed-off-by:
-
Chandan Rajendra authored
commit 30a9d7af upstream. The number of 'counters' elements needed in 'struct sg' is super_block->s_blocksize_bits + 2. Presently we have 16 'counters' elements in the array. This is insufficient for block sizes >= 32k. In such cases the memcpy operation performed in ext4_mb_seq_groups_show() would cause stack memory corruption. Fixes: c9de560dSigned-off-by:
Chandan Rajendra <chandan@linux.vnet.ibm.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Chandan Rajendra authored
commit 69e43e8c upstream. 'border' variable is set to a value of 2 times the block size of the underlying filesystem. With 64k block size, the resulting value won't fit into a 16-bit variable. Hence this commit changes the data type of 'border' to 'unsigned int'. Fixes: c9de560dSigned-off-by:
-
Bart Van Assche authored
commit d15bb3a6 upstream. It is required to hold the queue lock when calling blk_run_queue_async() to avoid that a race between blk_run_queue_async() and blk_cleanup_queue() is triggered. Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
-
Kyle Roeschley authored
commit 7a3cc2a7 upstream. On Zynq, we haven't been reserving the correct amount of DMA-incapable RAM to keep DMA away from it (per the Zynq TRM Section 4.1, it should be the first 512k). In older kernels, this was masked by the memblock_reserve call in arm_memblock_init(). Now, reserve the correct amount excplicitly rather than relying on swapper_pg_dir, which is an address and not a size anyway. Fixes: 46f5b960 ("ARM: zynq: Reserve not DMAable space in front of the kernel") Signed-off-by:
Kyle Roeschley <kyle.roeschley@ni.com> Tested-by:
Nathan Rossi <nathan@nathanrossi.com> Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Dan Carpenter authored
commit c95a9f83 upstream. We normally use the passed in gfp flags for allocations, it's just these two which were missed. Fixes: 22d45f01 ("usb/xhci: replace pci_*_consistent() with dma_*_coherent()") Cc: Mathias Nyman <mathias.nyman@intel.com> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Johan Hovold authored
commit 99e5cde5 upstream. Make sure to drop any device reference taken by vio_find_node() when adding and removing virtual I/O slots. Fixes: 5eeb8c63 ("[PATCH] PCI Hotplug: rpaphp: Move VIO registration") Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Johan Hovold authored
commit 815a7141 upstream. Make sure to drop any reference taken by bus_find_device() when creating devices during init and driver registration. Fixes: 55347cc9 ("[POWERPC] ibmebus: Add device creation and bus probing based on of_device") Signed-off-by:
-
Johan Hovold authored
commit fe0f3168 upstream. Make sure to drop any reference taken by bus_find_device() in the sysfs callbacks that are used to create and destroy devices based on device-tree entries. Fixes: 6bccf755 ("[POWERPC] ibmebus: dynamic addition/removal of adapters, some code cleanup") Signed-off-by:
-
Christopher Spinrath authored
commit 72649a46 upstream. According to the schematics of CompuLab's sbc-fx6 baseboard and the vendor devicetree GPIO_16 is *not* muxed to ENET_REF_CLK but to SPDIF_IN. Remove the wrong pinctrl setting. Fixes: 682d055e ("ARM: dts: Add initial support for cm-fx6.") Signed-off-by:
Christopher Spinrath <christopher.spinrath@rwth-aachen.de> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> [bwh: Backported to 3.16: adjust indentation] Signed-off-by:
-
Alex Porosanu authored
commit d128af17 upstream. The AEAD givenc descriptor relies on moving the IV through the output FIFO and then back to the CTX2 for authentication. The SEQ FIFO STORE could be scheduled before the data can be read from OFIFO, especially since the SEQ FIFO LOAD needs to wait for the SEQ FIFO LOAD SKIP to finish first. The SKIP takes more time when the input is SG than when it's a contiguous buffer. If the SEQ FIFO LOAD is not scheduled before the STORE, the DECO will hang waiting for data to be available in the OFIFO so it can be transferred to C2. In order to overcome this, first force transfer of IV to C2 by starting the "cryptlen" transfer first and then starting to store data from OFIFO to the output buffer. Fixes: 1acebad3 ("crypto: caam - faster aead implementation") Signed-off-by:
Alex Porosanu <alexandru.porosanu@nxp.com> Signed-off-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Linus Walleij authored
commit 295070e9 upstream. The regulator has never been properly enabled, it has been dormant all the time. It's strange that MMC was working at all, but it likely worked by the signals going through the levelshifter and reaching the card anyways. Fixes: 3615a34e ("regulator: add STw481x VMMC driver") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Alan Stern authored
commit ccdb6be9 upstream. The UHCI controllers in Intel chipsets rely on a platform-specific non-PME mechanism for wakeup signalling. They can generate wakeup signals even though they don't support PME. We need to let the USB core know this so that it will enable runtime suspend for UHCI controllers. Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
-
Alan Stern authored
commit 6496ebd7 upstream. One some systems, the firmware does not allow certain PCI devices to be put in deep D-states. This can cause problems for wakeup signalling, if the device does not support PME# in the deepest allowed suspend state. For example, Pierre reports that on his system, ACPI does not permit his xHCI host controller to go into D3 during runtime suspend -- but D3 is the only state in which the controller can generate PME# signals. As a result, the controller goes into runtime suspend but never wakes up, so it doesn't work properly. USB devices plugged into the controller are never detected. If the device relies on PME# for wakeup signals but is not capable of generating PME# in the target state, the PCI core should accurately report that it cannot do wakeup from runtime suspend. This patch modifies the pci_dev_run_wake() routine to add this check. Reported-by:
Pierre de Villemereuil <flyos@mailoo.org> Tested-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Kashyap Desai authored
commit 18e1c7f6 upstream. For SRIOV enabled firmware, if there is a OCR(online controller reset) possibility driver set the convert flag to 1, which is not happening if there are outstanding commands even after 180 seconds. As driver does not set convert flag to 1 and still making the OCR to run, VF(Virtual function) driver is directly writing on to the register instead of waiting for 30 seconds. Setting convert flag to 1 will cause VF driver will wait for 30 secs before going for reset. Signed-off-by:
Kiran Kumar Kasturi <kiran-kumar.kasturi@broadcom.com> Signed-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
-
Eric Sandeen authored
commit 4dfce57d upstream. There have been several reports over the years of NULL pointer dereferences in xfs_trans_log_inode during xfs_fsr processes, when the process is doing an fput and tearing down extents on the temporary inode, something like: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 PID: 29439 TASK: ffff880550584fa0 CPU: 6 COMMAND: "xfs_fsr" [exception RIP: xfs_trans_log_inode+0x10] #9 [ffff8800a57bbbe0] xfs_bunmapi at ffffffffa037398e [xfs] #10 [ffff8800a57bbce8] xfs_itruncate_extents at ffffffffa0391b29 [xfs] #11 [ffff8800a57bbd88] xfs_inactive_truncate at ffffffffa0391d0c [xfs] #12 [ffff8800a57bbdb8] xfs_inactive at ffffffffa0392508 [xfs] #13 [ffff8800a57bbdd8] xfs_fs_evict_inode at ffffffffa035907e [xfs] #14 [ffff8800a57bbe00] evict at ffffffff811e1b67 #15 [ffff8800a57bbe28] iput at ffffffff811e23a5 #16 [ffff8800a57bbe58] dentry_kill at ffffffff811dcfc8 #17 [ffff8800a57bbe88] dput at ffffffff811dd06c #18 [ffff8800a57bbea8] __fput at ffffffff811c823b #19 [ffff8800a57bbef0] ____fput at ffffffff811c846e #20 [ffff8800a57bbf00] task_work_run at ffffffff81093b27 #21 [ffff8800a57bbf30] do_notify_resume at ffffffff81013b0c #22 [ffff8800a57bbf50] int_signal at ffffffff8161405d As it turns out, this is because the i_itemp pointer, along with the d_ops pointer, has been overwritten with zeros when we tear down the extents during truncate. When the in-core inode fork on the temporary inode used by xfs_fsr was originally set up during the extent swap, we mistakenly looked at di_nextents to determine whether all extents fit inline, but this misses extents generated by speculative preallocation; we should be using if_bytes instead. This mistake corrupts the in-memory inode, and code in xfs_iext_remove_inline eventually gets bad inputs, causing it to memmove and memset incorrect ranges; this became apparent because the two values in ifp->if_u2.if_inline_ext[1] contained what should have been in d_ops and i_itemp; they were memmoved due to incorrect array indexing and then the original locations were zeroed with memset, again due to an array overrun. Fix this by properly using i_df.if_bytes to determine the number of extents, not di_nextents. Thanks to dchinner for looking at this with me and spotting the root cause. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Reviewed-by:
Brian Foster <bfoster@redhat.com> Signed-off-by:
Dave Chinner <david@fromorbit.com> [bwh: Backported to 3.16: adjust indentation] Signed-off-by:
-
Guenter Roeck authored
commit 328cf692 upstream. If CONFIG_ETRAX_AXISFLASHMAP is not configured, the flash rescue image object file is empty. With recent versions of binutils, this results in the following build error. cris-linux-objcopy: error: the input file 'arch/cris/boot/rescue/rescue.o' has no sections This is seen, for example, when trying to build cris:allnoconfig with recently generated toolchains. Since it does not make sense to build a flash rescue image if there is no flash, only build it if CONFIG_ETRAX_AXISFLASHMAP is enabled. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Fixes: 66ab3a74 ("CRIS: Merge machine dependent boot/compressed ..") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by:
-
Govindarajulu Varadarajan authored
commit 17197236 upstream. Driver sets the skb l4/l3 hash based on NIC_CFG_RSS_HASH_TYPE_*, which is bit mask. This is wrong. Hw actually provides us enum. Use CQ_ENET_RQ_DESC_RSS_TYPE_* to set l3 and l4 hash type. Fixes: bf751ba8 ("driver/net: enic: record q_number and rss_hash for skb") Signed-off-by:
Govindarajulu Varadarajan <_govind@gmx.com> Signed-off-by:
David S. Miller <davem@davemloft.net> [bwh: Backported to 3.16: drop the version bump] Signed-off-by:
-
Patrik Jakobsson authored
commit 0a97c81a upstream. Hook up drm_compat_ioctl to support 32-bit userspace on 64-bit kernels. It turns out that N2600 and N2800 comes with 64-bit enabled. We previously assumed there where no such systems out there. Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20161101144315.2955-1-patrik.r.jakobsson@gmail.comSigned-off-by:
-
