- 05 Dec, 2019 40 commits
-
-
Hans van Kranenburg authored
[ Upstream commit da612e31 ] RAID5 and RAID6 profile store one copy of the data, not 2 or 3. These values are not yet used anywhere so there's no change. Reviewed-by:
Nikolay Borisov <nborisov@suse.com> Signed-off-by:
Hans van Kranenburg <hans.van.kranenburg@mendix.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Nikolay Borisov authored
[ Upstream commit fc8a168a ] Before btrfs_map_bio submits all stripe bios it does a number of checks to ensure the device for every stripe is present. However, it doesn't do a DEV_STATE_MISSING check, instead this is relegated to the lower level btrfs_schedule_bio (in the async submission case, sync submission doesn't check DEV_STATE_MISSING at all). Additionally btrfs_schedule_bios does the duplicate device->bdev check which has already been performed in btrfs_map_bio. This patch moves the DEV_STATE_MISSING check in btrfs_map_bio and removes the duplicate device->bdev check. Doing so ensures that no bio cloning/submission happens for both async/sync requests in the face of missing device. This makes the async io submission path slightly shorter in terms of instruction count. No functional changes. Reviewed-by:
Josef Bacik <josef@toxicpanda.com> Reviewed-by:
Anand Jain <anand.jain@oracle.com> Signed-off-by:
-
Roger Quadros authored
[ Upstream commit 8dc7623b ] PHY model is being used on omap5 platforms even if port mode is not OMAP_EHCI_PORT_MODE_PHY. So don't guess if PHY is required or not based on PHY mode. If PHY is provided in device tree, it must be required. So, if devm_usb_get_phy_by_phandle() gives us an error code other than -ENODEV (no PHY) then error out. This fixes USB Ethernet on omap5-uevm if PHY happens to probe after EHCI thus causing a -EPROBE_DEFER. Cc: Johan Hovold <johan@kernel.org> Cc: Ladislav Michl <ladis@linux-mips.org> Reported-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Roger Quadros <rogerq@ti.com> Tested-by:
Tony Lindgren <tony@atomide.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Boris Brezillon authored
[ Upstream commit 73277443 ] The opcodes used by the controller when doing batched page prog should be written in NFC_REG_WCMD_SET not FC_REG_RCMD_SET. Luckily, the default NFC_REG_WCMD_SET value matches the one we set in the driver which explains why we didn't notice the problem. Fixes: 614049a8 ("mtd: nand: sunxi: add support for DMA assisted operations") Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
-
Jerome Brunet authored
[ Upstream commit 18f92bc0 ] On errors, if we don't stop the descriptor chain, it may continue to run and raise IRQ after we have called mmc_request_done(). This is bad because we won't be able to get cmd anymore and properly deal with the IRQ. This patch makes sure the descriptor chain is stopped before calling mmc_request_done() Fixes: 79ed05e3 ("mmc: meson-gx: add support for descriptor chain mode") Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Lepton Wu authored
[ Upstream commit 8236b08c ] The old code always starts from fixed port for VMADDR_PORT_ANY. Sometimes when VMM crashed, there is still orphaned vsock which is waiting for close timer, then it could cause connection time out for new started VM if they are trying to connect to same port with same guest cid since the new packets could hit that orphaned vsock. We could also fix this by doing more in vhost_vsock_reset_orphans, but any way, it should be better to start from a random local port instead of a fixed one. Signed-off-by:
Lepton Wu <ytht.net@gmail.com> Reviewed-by:
Jorgen Hansen <jhansen@vmware.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Atul Gupta authored
[ Upstream commit 6422ccc5 ] listen fails when more than one tls capable device is registered. tls_hw_hash is called for each dev which loops again for each cdev_list causing listen failure. Hence call chtls_listen_start/stop for specific device than loop over all devices. Signed-off-by:
Atul Gupta <atul.gupta@chelsio.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 7392aa08 which is commit 7671ce21 upstream. It should not have been selected for a stable kernel as it breaks the nVMX regression tests. Reported-by:
Jack Wang <jack.wang.usish@gmail.com> Reported-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: Sean Christopherson <sean.j.christopherson@intel.com> Cc: Jim Mattson <jmattson@google.com> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 9fe573d5 which is commit b7031fd4 upstream. It should not have been selected for a stable kernel as it breaks the nVMX regression tests. Reported-by:
-
Jim Mattson authored
[ Upstream commit 0023ef39 ] RDTSCP is supported in legacy mode as well as long mode. The IA32_TSC_AUX MSR should be set to the correct guest value before entering any guest that supports RDTSCP. Fixes: 4e47c7a6 ("KVM: VMX: Add instruction rdtscp support for guest") Signed-off-by:
Jim Mattson <jmattson@google.com> Reviewed-by:
Peter Shier <pshier@google.com> Reviewed-by:
Marc Orr <marcorr@google.com> Reviewed-by:
Liran Alon <liran.alon@oracle.com> Reviewed-by:
Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit c5510b8d ] If CONFIG_GPOILIB is not set, the stub of gpio_to_desc() should return the same type of error as regular version: NULL. All the callers compare the return value of gpio_to_desc() against NULL, so returned ERR_PTR would be treated as non-error case leading to dereferencing of error value. Fixes: 79a9becd ("gpiolib: export descriptor-based GPIO interface") Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Marek Vasut authored
[ Upstream commit 92f45ebe ] The PCAL_PINCTRL_MASK is too large. The extended register block on PCAL6524, which is the largest chip with this block, has the block limited to address range 0x40..0x7f. This is because the bit 7 in the command register is used for the Address Increment functionality. Trim the mask to 0x60 to match the datasheet and to prevent accidental overwrite of the AI bit. Signed-off-by:
Marek Vasut <marek.vasut+renesas@gmail.com> Reviewed-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
-
Sara Sharon authored
[ Upstream commit 956343a6 ] command len is set too early in the code, since when building AMSDU, the size changes. This causes the byte count table to have the wrong size. Fixes: a0ec0169 ("iwlwifi: support new tx api") Signed-off-by:
Sara Sharon <sara.sharon@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Sara Sharon authored
[ Upstream commit 0916224e ] When removing the driver, the following flow can happen: 1. host command is in progress, for example at index 68. 2. RX interrupt is received with the response. 3. Before it is processed, the remove flow kicks in, and calls iwl_pcie_txq_unmap. The function cleans all DMA, and promotes the read pointer to 69. 4. RX thread proceeds with the processing, and is calling iwl_pcie_cmdq_reclaim, which will print this error: iwl_pcie_cmdq_reclaim: Read index for DMA queue txq id (0), index 4 is out of range [0-256] 69 69. Detect this situation, and avoid the print. Change it to warning while at it, to make such issues more noticeable in the future. Signed-off-by:
-
Avraham Stern authored
[ Upstream commit 7bc24682 ] When traffic load is not low or low latency is active, TCM schedules re-evaluation work so in case traffic stops TCM will detect that traffic load has become low or that low latency is no longer active. However, if TCM is paused when the re-evaluation work runs, it does not re-evaluate and the re-evaluation work is no longer scheduled. As a result, TCM will not indicate that low latency is no longer active or that traffic load is low when traffic stops. Fix this by forcing TCM re-evaluation when TCM is resumed in case low latency is active or traffic load is not low. Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
-
Luca Coelho authored
[ Upstream commit 64866e5d ] This function is only half-used by mvm (i.e. only the nvm_version part matters, since the calibration version is irrelevant), so it's pointless to export it from iwlwifi. If mvm uses this function, it has the additional complexity of setting the calib version to a bogus value on all cfg structs. To avoid this, move the function to dvm and make a simple comparison of the nvm_version in mvm instead. Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit 4722a3e6 ] This commit fixes some build issues. The first issue is the breakage of linux.bin.ub target since commit ece97f3a ("microblaze: Fix simpleImage format generation") because the addition of UIMAGE_{IN,OUT} affected it. make ARCH=microblaze CROSS_COMPILE=microblaze-linux- linux.bin.ub [ snip ] OBJCOPY arch/microblaze/boot/linux.bin UIMAGE arch/microblaze/boot/linux.bin.ub.ub /usr/bin/mkimage: Can't open arch/microblaze/boot/linux.bin.ub: No such file or directory make[1]: *** [arch/microblaze/boot/Makefile;14: arch/microblaze/boot/linux.bin.ub] Error 1 make: *** [arch/microblaze/Makefile;83: linux.bin.ub] Error 2 The second issue is the use of the "if_changed" multiple times for the same target. As commit 92a47286 ("x86/boot: Fix if_changed build flip/flop bug") pointed out, this never works properly. Moreover, generating multiple images as a side-effect is confusing. Let's split the build recipe for each image. simpleImage.<dt>*.unstrip is just a copy of vmlinux. simpleImage.<dt> and simpleImage.<dt>.ub are created in the same way as linux.bin and linux.bin.ub, respectively. I kept simpleImage.* recipes independent of linux.bin.* ones to not change the behavior. Lastly, this commit fixes "make ARCH=microblaze clean". Previously, it only cleaned up the unstrip image. Now, all the simpleImage files are cleaned. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit 2e14f94c ] To prepare for more fixes, move this to arch/microblaze/Makefile. Otherwise, the same "... is ready" would be printed multiple times. Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit bafcc61d ] "make ARCH=microblaze help" mentions simpleImage.<dt>.unstrip, but it is not a real Make target. It does not work because Makefile assumes "system.unstrip" is the name of DT. $ make ARCH=microblaze CROSS_COMPILE=microblaze-linux- simpleImage.system.unstrip [ snip ] make[1]: *** No rule to make target 'arch/microblaze/boot/dts/system.unstrip.dtb', needed by 'arch/microblaze/boot/dts/system.dtb'. Stop. make: *** [Makefile;1060: arch/microblaze/boot/dts] Error 2 make: *** Waiting for unfinished jobs.... simpleImage.<dt> works like a phony target that generates multiple images. Reflect the real behavior. I removed the DT directory path information because it is already explained a few lines below. While I am here, I deleted the redundant *_defconfig explanation. The top-level Makefile caters to list available defconfig files: mmu_defconfig - Build for mmu nommu_defconfig - Build for nommu Signed-off-by:
-
Pan Bian authored
[ Upstream commit e5420877 ] The UBI device reference is dropped but then the device is used as a parameter of ubi_err. The bug is introduced in changing ubi_err's behavior. The old ubi_err does not require a UBI device as its first parameter, but the new one does. Fixes: 32608703 ("UBI: Extend UBI layer debug/messaging capabilities") Signed-off-by:
Pan Bian <bianpan2016@163.com> Reviewed-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Pan Bian authored
[ Upstream commit b95f83ab ] The MTD device reference is dropped via put_mtd_device, however its field ->index is read and passed to ubi_msg. To fix this, the patch moves the reference dropping after calling ubi_msg. Signed-off-by:
-
Gabor Juhos authored
[ Upstream commit d62e98ed ] When ubifs is build without the LZO compressor and no compressor is given the creation of the default file system will fail. before selection the LZO compressor check if it is present and if not fall back to the zlib or none. Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Sagi Grimberg authored
[ Upstream commit 092ff052 ] free the controller discard_page correctly. Fixes: cb5b7262 ("nvme: provide fallback for discard alloc failure") Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Darrick J. Wong authored
[ Upstream commit 64bafd2f ] Since mkfs always formats the filesystem with the realtime bitmap and summary inodes immediately after the root directory, we should expect that both of them are present and loadable, even if there isn't a realtime volume attached. There's no reason to skip this if rbmino == NULLFSINO; in fact, this causes an immediate crash if the there /is/ a realtime volume and someone writes to it. Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by:
Bill O'Donnell <billodo@redhat.com> Signed-off-by:
-
Shenghui Wang authored
[ Upstream commit 79b79146 ] A fresh backing device is not attached to any cache_set, and has no writeback kthread created until first attached to some cache_set. But bch_cached_dev_writeback_init run " dc->writeback_running = true; WARN_ON(test_and_clear_bit(BCACHE_DEV_WB_RUNNING, &dc->disk.flags)); " for any newly formatted backing devices. For a fresh standalone backing device, we can get something like following even if no writeback kthread created: ------------------------ /sys/block/bcache0/bcache# cat writeback_running 1 /sys/block/bcache0/bcache# cat writeback_rate_debug rate: 512.0k/sec dirty: 0.0k target: 0.0k proportional: 0.0k integral: 0.0k change: 0.0k/sec next io: -15427384ms The none ZERO fields are misleading as no alive writeback kthread yet. Set dc->writeback_running false as no writeback thread created in bch_cached_dev_writeback_init(). We have writeback thread created and woken up in bch_cached_dev_writeback _start(). Set dc->writeback_running true before bch_writeback_queue() called, as a writeback thread will check if dc->writeback_running is true before writing back dirty data, and hung if false detected. After the change, we can get the following output for a fresh standalone backing device: ----------------------- /sys/block/bcache0/bcache$ cat writeback_running 0 /sys/block/bcache0/bcache# cat writeback_rate_debug rate: 0.0k/sec dirty: 0.0k target: 0.0k proportional: 0.0k integral: 0.0k change: 0.0k/sec next io: 0ms v1 -> v2: Set dc->writeback_running before bch_writeback_queue() called, Signed-off-by:
Shenghui Wang <shhuiw@foxmail.com> Signed-off-by:
Coly Li <colyli@suse.de> Signed-off-by:
-
Shenghui Wang authored
[ Upstream commit ae171023 ] debugfs_remove and debugfs_remove_recursive will check if the dentry pointer is NULL or ERR, and will do nothing in that case. Remove the check in cache_set_free and bch_debug_init. Signed-off-by:
-
Pan Bian authored
[ Upstream commit afbb1947 ] entry is released via usb_put_urb just after calling usb_submit_urb. However, entry is used if the submission fails, resulting in a use after free bug. The patch fixes this. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Madhan Mohan R authored
[ Upstream commit 58e4bbea ] Along with F2 watermark (existing) configuration, F1 MesBusyCtrl should be enabled & sdio device RX FIFO watermark should be configured to avoid overflow errors. Reviewed-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Madhan Mohan R <madhanmohan.r@cypress.com> Signed-off-by:
Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by:
-
Wright Feng authored
[ Upstream commit e1a08730 ] We got SDIO_CRC_ERROR with 4373 on SDR104 when doing bi-directional throughput test. Enable watermark to 256 to guarantee the operation stability. Reviewed-by:
Wright Feng <wright.feng@cypress.com> Signed-off-by:
-
Brian Norris authored
[ Upstream commit 4cb777c6 ] Currently, snippets of this file look like: rx rates (in Mbps): 0=1M 1=2M2=5.5M 3=11M 4=6M 5=9M 6=12M 7=18M 8=24M 9=36M 10=48M 11=54M12-27=MCS0-15(BW20) 28-43=MCS0-15(BW40) 44-53=MCS0-9(VHT:BW20)54-63=MCS0-9(VHT:BW40)64-73=MCS0-9(VHT:BW80) ... noise_flr[--96dBm] = 22 noise_flr[--95dBm] = 149 noise_flr[--94dBm] = 9 noise_flr[--93dBm] = 2 We're missing some spaces, and we're adding a minus sign ('-') on values that are already negative signed integers. Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Pan Bian authored
[ Upstream commit 1dcd9429 ] There are two defects: (1) passing a NULL bss to mwifiex_save_hidden_ssid_channels will result in NULL dereference, (2) using bss after dropping the reference to it via cfg80211_put_bss. To fix them, the patch moves the buggy code to the branch that bss is not NULL and puts it before cfg80211_put_bss. Signed-off-by:
-
Laurent Pinchart authored
[ Upstream commit 6f61a2c8 ] A typo in the adv7180 DT node prevents successful probing of the VIN. Fix it. Fixes: 6a0942c2 ("arm64: dts: renesas: draak: Describe CVBS input") Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Eric Biggers authored
[ Upstream commit 0ac6b8fb ] CRYPTO_MSG_GETALG in NLM_F_DUMP mode sometimes doesn't return all registered crypto algorithms, because it doesn't support incremental dumps. crypto_dump_report() only permits itself to be called once, yet the netlink subsystem allocates at most ~64 KiB for the skb being dumped to. Thus only the first recvmsg() returns data, and it may only include a subset of the crypto algorithms even if the user buffer passed to recvmsg() is large enough to hold all of them. Fix this by using one of the arguments in the netlink_callback structure to keep track of the current position in the algorithm list. Then userspace can do multiple recvmsg() on the socket after sending the dump request. This is the way netlink dumps work elsewhere in the kernel; it's unclear why this was different (probably just an oversight). Also fix an integer overflow when calculating the dump buffer size hint. Fixes: a38f7907 ("crypto: Add userspace configuration API") Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Harald Freudenberger authored
[ Upstream commit 42a87d41 ] Until now there is no way to reset a AP queue or card. Driving a card or queue offline and online again does only toggle the 'software' online state. The only way to trigger a (hardware) reset is by running hot-unplug/hot-plug for example on the HMC. This patch makes the queue reset attribute in sysfs writable. Writing into this attribute triggers a reset on the AP queue's state machine. So the AP queue is flushed and state machine runs through the initial states which cause a reset (PQAP(RAPQ)) and a re-registration to interrupts (PQAP(AQIC)) if available. The reset sysfs attribute is writable by root only. So only an administrator is allowed to initiate a reset of AP queues. Please note that the queue's counter values are left untouched by the reset. Signed-off-by:
Harald Freudenberger <freude@linux.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit cb5b7262 ] When boxes are run near (or to) OOM, we have a problem with the discard page allocation in nvme. If we fail allocating the special page, we return busy, and it'll get retried. But since ordering is honored for dispatch requests, we can keep retrying this same IO and failing. Behind that IO could be requests that want to free memory, but they never get the chance. Allocate a fixed discard page per controller for a safe fallback, and use that if the initial allocation fails. Signed-off-by:
Keith Busch <keith.busch@intel.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Giridhar Malavali authored
[ Upstream commit 835aa4f2 ] This patch fixes NVMe discovery by setting SKIP_PRLI flag, so that PRLI is driven by driver and is retried when the NPIV port is detected to have NVMe capability. Signed-off-by:
Giridhar Malavali <gmalavali@marvell.com> Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Himanshu Madhani authored
[ Upstream commit 5e6803b4 ] This patch fixes issues with NPIV port with FC-NVMe. Clean up code for remoteport delete and also call nvme_delete when deleting VPs. Signed-off-by:
-
James Smart authored
[ Upstream commit 719162bd ] Addition of support for if_type=6 missed several checks for interface type, resulting in the failure of several key management features such as firmware dump and loopback testing. Correct the checks on the if_type so that both SLI4 IF_TYPE's 2 and 6 are supported. Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 1a2fa02f ] Ignore acpi_device_fix_up_power() return value. If we return an error we end up with acpi_default_enumeration() still creating a platform- device for the device and we end up with the device still being used but without the special LPSS related handling which is not useful. Specicifically ignoring the error fixes the touchscreen no longer working after a suspend/resume on a Prowise PT301 tablet. This tablet has a broken _PS0 method on the touchscreen's I2C controller, causing acpi_device_fix_up_power() to fail, causing fallback to standard platform-dev handling and specifically causing acpi_lpss_save/restore_ctx to not run. The I2C controllers _PS0 method does actually turn on the device, but then does some more nonsense which fails when run during early boot trying to use I2C opregion handling on another not-yet registered I2C controller. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 4aa64677 ] WARNING: vmlinux.o(.text+0x13250): Section mismatch in reference from the function acs5k_i2c_init() to the (unknown reference) .init.data:(unknown) The function acs5k_i2c_init() references the (unknown reference) __initdata (unknown). This is often because acs5k_i2c_init lacks a __initdata annotation or the annotation of (unknown) is wrong. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
