- 20 Nov, 2019 40 commits
-
-
Guido Kiener authored
[ Upstream commit 9a831903 ] Fix uninitialized symbol 'actual' in function usbtmc_ioctl_clear. When symbol 'actual' is not initialized and usb_bulk_msg() fails, the subsequent kernel debug message shows a random value. Signed-off-by:
Guido Kiener <guido.kiener@rohde-schwarz.com> Fixes: dfee02ac ("usb: usbtmc: Fix ioctl USBTMC_IOCTL_CLEAR") Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Chunfeng Yun authored
[ Upstream commit 87173acc ] If the interval equal zero, needn't round up to power of two for the number of packets in each ESIT, so fix it. Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Tan Hu authored
[ Upstream commit 097f95d3 ] We configured iptables as below, which only allowed incoming data on established connections: iptables -t mangle -A PREROUTING -m state --state ESTABLISHED -j ACCEPT iptables -t mangle -P PREROUTING DROP When deleting a secondary address, current masquerade implements would flush all conntracks on this device. All the established connections on primary address also be deleted, then subsequent incoming data on the connections would be dropped wrongly because it was identified as NEW connection. So when an address was delete, it should only flush connections related with the address. Signed-off-by:
Tan Hu <tan.hu@zte.com.cn> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Alexandre Belloni authored
[ Upstream commit 7d61cbb9 ] The IRQ is requested before the struct rtc is allocated and registered, but this struct is used in the IRQ handler. This may lead to a NULL pointer dereference. Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc before requesting the IRQ. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Alexandre Belloni authored
[ Upstream commit 2ab78755 ] The default word_size and stride of 1 are correct for the tx4939. Also fix the nvmem folder name. Signed-off-by:
-
Alexandre Belloni authored
[ Upstream commit 1b4c794f ] Use rtc_add_group to add the common sysfs group to avoid a possible race condition. [Denis.Osterland@diehl.com: use to_i2c_client(dev->parent)] Signed-off-by:
Denis Osterland <Denis.Osterland@diehl.com> Signed-off-by:
-
Rob Herring authored
[ Upstream commit 11236ef5 ] SPI controller nodes should be named 'spi' rather than 'ssp'. Fixing the name enables dtc SPI bus checks. Cc: Vladimir Zapolskiy <vz@mleia.com> Cc: Sylvain Lemieux <slemieux.tyco@gmail.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Rob Herring authored
[ Upstream commit 09bae3b6 ] SPI controller nodes should be named 'spi' rather than 'ssp'. Fixing the name enables dtc SPI bus checks. Cc: Chanho Min <chanho.min@lge.com> Signed-off-by:
-
Rob Herring authored
[ Upstream commit e9f0878c ] dtc has new checks for SPI buses. Fix the warnings in node names. arch/arm64/boot/dts/amd/amd-overdrive.dtb: Warning (spi_bus_bridge): /smb/ssp@e1030000: node name for SPI buses should be 'spi' arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dtb: Warning (spi_bus_bridge): /smb/ssp@e1030000: node name for SPI buses should be 'spi' arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dtb: Warning (spi_bus_bridge): /smb/ssp@e1030000: node name for SPI buses should be 'spi' Cc: Brijesh Singh <brijeshkumar.singh@amd.com> Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Finn Thain authored
[ Upstream commit 6b0e87a6 ] The SR_RST bit isn't latched. Hence, detecting a bus reset isn't reliable. When it is detected, the right thing to do is to drop all connected and disconnected commands. The code for that is already present so refactor it and call it when SR_RST is set. Tested-by:
Michael Schmitz <schmitzmic@gmail.com> Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Finn Thain authored
[ Upstream commit ca694afa ] The X3T9.2 specification (draft) says, under "6.1.4.2 RESELECTION time-out procedure", that a target may assert RST or go to BUS FREE phase if the initiator does not respond within 200 us. Something like this has been observed with AztecMonster II target. When it happens, all we can do is wait for the target to try again. Tested-by:
-
Finn Thain authored
[ Upstream commit 08267216 ] The X3T9.2 specification (draft) says, under "6.1.4.1 RESELECTION", ... The reselected initiator shall then assert the BSY signal within a selection abort time of its most recent detection of being reselected; this is required for correct operation of the time-out procedure. The selection abort time is only 200 us which may be insufficient time for a printk() call. Move the diagnostics to the error paths. Tested-by:
-
Finn Thain authored
[ Upstream commit 45ddc1b2 ] When NCR5380_abort() returns FAILED, the driver forgets that the target is still busy. Hence, further commands may be sent to the target, which may fail during selection and produce the error message, "reselection after won arbitration?". Prevent this by leaving the busy flag set when NCR5380_abort() fails. Tested-by:
-
Finn Thain authored
[ Upstream commit 7ef55f67 ] The X3T9.2 specification (draft) says, under "6.1.4.1 RESELECTION", that "the initiator shall not respond to a RESELECTION phase if other than two SCSI ID bits are on the DATA BUS." This issue (too many bits set) has been observed in the wild, so add a check. Tested-by:
-
Finn Thain authored
[ Upstream commit 07035651 ] When sense data is valid, call set_driver_byte(cmd, DRIVER_SENSE). Otherwise some callers of scsi_execute() will ignore sense data. Don't set DID_ERROR or DID_RESET just because sense data is missing. Tested-by:
-
Finn Thain authored
[ Upstream commit 7c8ed783 ] This is mostly needed because an AztecMonster II target has been observed disconnecting REQUEST SENSE commands and then failing to reselect properly. Suggested-by:
-
Finn Thain authored
[ Upstream commit dad8261e ] The return value is taken to mean "retry" or "don't retry". Change it to bool to improve readability. Fix related comments. No functional change. Tested-by:
-
Hannes Reinecke authored
[ Upstream commit 1aeeeed7 ] When doing a host reset we should be clearing all outstanding commands, not just the command triggering the reset. [mkp: adjusted Hannes' SoB address] Signed-off-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Cc: Ondrey Zary <linux@rainbow-software.org> Signed-off-by:
-
Ilan Peer authored
[ Upstream commit 6f3df8c1 ] Support for setting keys for TKIP cipher suite was mistakenly removed for AP mode. Fix this. Fixes: 85aeb58c ("iwlwifi: mvm: Enable security on new TX API") Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Sara Sharon authored
[ Upstream commit 7126b6f2 ] Current FIFO size calculation is wrong for two reasons: - We access lmac 0 by default - We don't take 11ax into consideration. Fix both. Signed-off-by:
Sara Sharon <sara.sharon@intel.com> Signed-off-by:
-
Golan Ben Ami authored
[ Upstream commit 81f0c661 ] Today, the length of a debug message in iwl_trans_pcie_reclaim may pass the MAX_MSG_LEN, which is 110. An example for this kind of message is: 'iwl_trans_pcie_reclaim: Read index for DMA queue txq id (2), last_to_free 65535 is out of range [0-65536] 2 2.' Cut the message a bit so it will fit the allowed MAX_MSG_LEN. Signed-off-by:
Golan Ben Ami <golan.ben.ami@intel.com> Signed-off-by:
-
Johannes Berg authored
[ Upstream commit 53f474e6 ] If the incoming frame should be an A-MSDU, it may already be one, for example in the case of NAN multicast being encapsulated in an A-MSDU. Thus, use the GSO algorithm to build A-MSDU only if the skb actually contains GSO data. Fixes: 6ffe5de3 ("iwlwifi: pcie: add AMSDU to gen2") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
[ Upstream commit 6f68cc36 ] Annotate the compressed BA notification array sizes and make both of them 0-length since the length of 1 is just confusing - it may be different than that and the offset to the second one needs to be calculated in the C code anyhow. Signed-off-by:
-
Sara Sharon authored
[ Upstream commit 84fb372c ] For newer devices we have higher range of periphery addresses. Currently it is masked out, so we end up reading another address. Signed-off-by:
-
Erel Geron authored
[ Upstream commit a4028772 ] The non-shared antenna was wrong for 22000 device series. Fix it to ANT_B for correct antenna preference by coex in MVM driver. Fixes: e34d975e ("iwlwifi: Add a000 HW family support") Signed-off-by:
Erel Geron <erelx.geron@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
[ Upstream commit 79f25b10 ] We can dump data from the firmware either when it crashes, or when the firmware is alive. Not all the data is available if the firmware is running (like the Tx / Rx FIFOs which are available only when the firmware is halted), so we first check that the firmware is alive to compute the required size for the dump and then fill the buffer with the data. When we allocate the buffer, we test the STATUS_FW_ERROR bit to check if the firmware is alive or not. This bit can be changed during the course of the dump since it is modified in the interrupt handler. We hit a case where we allocate the buffer while the firmware is sill working, and while we start to fill the buffer, the firmware crashes. Then we test STATUS_FW_ERROR again and decide to fill the buffer with data like the FIFOs even if no room was allocated for this data in the buffer. This means that we overflow the buffer that was allocated leading to memory corruption. To fix this, test the STATUS_FW_ERROR bit only once and rely on local variables to check if we should dump fifos or other firmware components. Fixes: 04fd2c28 ("iwlwifi: mvm: add rxf and txf to dump data") Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Dan Aloni authored
[ Upstream commit 3944f139 ] The encryption mode of pkcs1pad never uses out_sg and out_buf, so there's no need to allocate the buffer, which presently is not even being freed. CC: Herbert Xu <herbert@gondor.apana.org.au> CC: linux-crypto@vger.kernel.org CC: "David S. Miller" <davem@davemloft.net> Signed-off-by:
Dan Aloni <dan@kernelim.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Christoph Manszewski authored
[ Upstream commit 6c12b6ba ] Fix misalignment of continued argument list. Signed-off-by:
Christoph Manszewski <c.manszewski@samsung.com> Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Acked-by:
Kamil Konieczny <k.konieczny@partner.samsung.com> Signed-off-by:
-
Christoph Manszewski authored
[ Upstream commit 5842cd44 ] Remove a race condition introduced by error path in functions: s5p_aes_interrupt and s5p_aes_crypt_start. Setting the busy field of struct s5p_aes_dev to false made it possible for s5p_tasklet_cb to change the req field, before s5p_aes_complete was called. Change the first parameter of s5p_aes_complete to struct ablkcipher_request. Before spin_unlock, make a copy of the currently handled request, to ensure s5p_aes_complete function call with the correct request. Signed-off-by:
-
Dexuan Cui authored
[ Upstream commit 2f285f46 ] A Generation-2 Linux VM on Hyper-V doesn't have the legacy PCI bus, and users always see the scary warning, which is actually harmless. Suppress it. Signed-off-by:
Dexuan Cui <decui@microsoft.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Michael Kelley <mikelley@microsoft.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: KY Srinivasan <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Cc: "devel@linuxdriverproject.org" <devel@linuxdriverproject.org> Cc: Olaf Aepfle <olaf@aepfle.de> Cc: Andy Whitcroft <apw@canonical.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Cc: Marcelo Cerri <marcelo.cerri@canonical.com> Cc: Josh Poulson <jopoulso@microsoft.com> Link: https://lkml.kernel.org/r/ <KU1P153MB0166D977DC930996C4BF538ABF1D0@KU1P153MB0166.APCP153.PROD.OUTLOOK.COM Signed-off-by:
-
Sanjay Kumar Konduri authored
[ Upstream commit 7cbfd1e2 ] observed sometimes data is coming with unaligned address from kernel BT stack. If unaligned address is passed, some data in payload is stripped when packet is loading to firmware and this results, BT connection timeout is happening. sh# hciconfig hci0 up Can't init device hci0: hci0 command 0x0c03 tx timeout Fixed this by moving the data to aligned address. Signed-off-by:
Sanjay Kumar Konduri <sanjay.konduri@redpinesignals.com> Signed-off-by:
Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Luiz Augusto von Dentz authored
[ Upstream commit a5c3021b ] If the remote is not able to fully utilize the MPS choosen recalculate the credits based on the actual amount it is sending that way it can still send packets of MTU size without credits dropping to 0. Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
-
Balakrishna Godavarthi authored
[ Upstream commit 7cf7846d ] Clearing HCI_UART_PROTO_READY will avoid usage of proto function pointers before running the proto close function pointer. There is chance of kernel crash, due to usage of non proto close function pointers after proto close. Signed-off-by:
Balakrishna Godavarthi <bgodavar@codeaurora.org> Signed-off-by:
-
Stuart Hayes authored
[ Upstream commit 6aecee6a ] The dell_rbu driver takes firmware update payloads and puts them in memory so the system BIOS can find them after a reboot. This sometimes fails (though rarely), because the memory containing the payload is in the CPU cache but never gets written back to main memory before the system is rebooted (CPU cache contents are lost on reboot). With this patch, the payload memory will be changed to uncachable to ensure that the payload is actually in main memory before the system is rebooted. Signed-off-by:
Stuart Hayes <stuart.w.hayes@gmail.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Rob Herring authored
[ Upstream commit 016add12 ] SPI controller nodes should be named 'spi' rather than 'ssp'. Fixing the name enables dtc SPI bus checks. Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Justin Ernst authored
[ Upstream commit 6b588594 ] We observe an oops in the skx_edac module during boot: EDAC MC0: Giving out device to module skx_edac controller Skylake Socket#0 IMC#0 EDAC MC1: Giving out device to module skx_edac controller Skylake Socket#0 IMC#1 EDAC MC2: Giving out device to module skx_edac controller Skylake Socket#1 IMC#0 ... EDAC MC13: Giving out device to module skx_edac controller Skylake Socket#0 IMC#1 EDAC MC14: Giving out device to module skx_edac controller Skylake Socket#1 IMC#0 EDAC MC15: Giving out device to module skx_edac controller Skylake Socket#1 IMC#1 Too many memory controllers: 16 EDAC MC: Removed device 0 for skx_edac Skylake Socket#0 IMC#0 We observe there are two memory controllers per socket, with a limit of 16. Raise the maximum number of memory controllers from 16 to 2 * MAX_NUMNODES (1024). [ bp: This is just a band-aid fix until we've sorted out the whole issue with the bus_type association and handling in EDAC and can get rid of this arbitrary limit. ] Signed-off-by:
Justin Ernst <justin.ernst@hpe.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
Russ Anderson <russ.anderson@hpe.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: linux-edac@vger.kernel.org Link: https://lkml.kernel.org/r/20180925143449.284634-1-justin.ernst@hpe.comSigned-off-by:
-
Arnd Bergmann authored
[ Upstream commit 46bdf777 ] The mlx4 driver produces a link error when it is configured as built-in while CONFIG_INFINIBAND_USER_ACCESS is set to =m: drivers/infiniband/hw/mlx4/main.o: In function `mlx4_ib_mmap': main.c:(.text+0x1af4): undefined reference to `rdma_user_mmap_io' The same function is called from mlx5, which already has a dependency to ensure we can call it, and from hns, which appears to suffer from the same problem. This adds the same dependency that mlx5 uses to the other two. Fixes: 6745d356 ("RDMA/hns: Use rdma_user_mmap_io") Fixes: c282da41 ("RDMA/mlx4: Use rdma_user_mmap_io") Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Chao Yu authored
[ Upstream commit 4a1728ca ] Mark inode dirty explicitly in the end of recover_inode() to make sure that all recoverable fields can be persisted later. Signed-off-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Chao Yu authored
[ Upstream commit f4474aa6 ] Testcase to reproduce this bug: 1. mkfs.f2fs -O extra_attr -O project_quota /dev/sdd 2. mount -t f2fs /dev/sdd /mnt/f2fs 3. touch /mnt/f2fs/file 4. sync 5. chattr -p 1 /mnt/f2fs/file 6. xfs_io -f /mnt/f2fs/file -c "fsync" 7. godown /mnt/f2fs 8. umount /mnt/f2fs 9. mount -t f2fs /dev/sdd /mnt/f2fs 10. lsattr -p /mnt/f2fs/file 0 -----------------N- /mnt/f2fs/file But actually, we expect the correct result is: 1 -----------------N- /mnt/f2fs/file The reason is we didn't recover inode.i_projid field during mount, fix it. Signed-off-by:
-
Jaegeuk Kim authored
[ Upstream commit 0a4daae5 ] This is related to ee70daab ("xfs: update i_size after unwritten conversion in dio completion") If we update i_size during dio_write, dio_read can read out stale data, which breaks xfstests/465. Reviewed-by:
-
