aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2020-07-02scsi: mpt3sas: Fix unlock imbalanceDamien Le Moal1-1/+1
In BRM_status_show(), if the condition "!ioc->is_warpdrive" tested on entry to the function is true, a "goto out" is called. This results in unlocking ioc->pci_access_mutex without this mutex lock being taken. This generates the following splat: [ 1148.539883] mpt3sas_cm2: BRM_status_show: BRM attribute is only for warpdrive [ 1148.547184] [ 1148.548708] ===================================== [ 1148.553501] WARNING: bad unlock balance detected! [ 1148.558277] 5.8.0-rc3+ #827 Not tainted [ 1148.562183] ------------------------------------- [ 1148.566959] cat/5008 is trying to release lock (&ioc->pci_access_mutex) at: [ 1148.574035] [<ffffffffc070b7a3>] BRM_status_show+0xd3/0x100 [mpt3sas] [ 1148.580574] but there are no more locks to release! [ 1148.585524] [ 1148.585524] other info that might help us debug this: [ 1148.599624] 3 locks held by cat/5008: [ 1148.607085] #0: ffff92aea3e392c0 (&p->lock){+.+.}-{3:3}, at: seq_read+0x34/0x480 [ 1148.618509] #1: ffff922ef14c4888 (&of->mutex){+.+.}-{3:3}, at: kernfs_seq_start+0x2a/0xb0 [ 1148.630729] #2: ffff92aedb5d7310 (kn->active#224){.+.+}-{0:0}, at: kernfs_seq_start+0x32/0xb0 [ 1148.643347] [ 1148.643347] stack backtrace: [ 1148.655259] CPU: 73 PID: 5008 Comm: cat Not tainted 5.8.0-rc3+ #827 [ 1148.665309] Hardware name: HGST H4060-S/S2600STB, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [ 1148.678394] Call Trace: [ 1148.684750] dump_stack+0x78/0xa0 [ 1148.691802] lock_release.cold+0x45/0x4a [ 1148.699451] __mutex_unlock_slowpath+0x35/0x270 [ 1148.707675] BRM_status_show+0xd3/0x100 [mpt3sas] [ 1148.716092] dev_attr_show+0x19/0x40 [ 1148.723664] sysfs_kf_seq_show+0x87/0x100 [ 1148.731193] seq_read+0xbc/0x480 [ 1148.737882] vfs_read+0xa0/0x160 [ 1148.744514] ksys_read+0x58/0xd0 [ 1148.751129] do_syscall_64+0x4c/0xa0 [ 1148.757941] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1148.766240] RIP: 0033:0x7f1230566542 [ 1148.772957] Code: Bad RIP value. [ 1148.779206] RSP: 002b:00007ffeac1bcac8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 1148.790063] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f1230566542 [ 1148.800284] RDX: 0000000000020000 RSI: 00007f1223460000 RDI: 0000000000000003 [ 1148.810474] RBP: 00007f1223460000 R08: 00007f122345f010 R09: 0000000000000000 [ 1148.820641] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000000000 [ 1148.830728] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 Fix this by returning immediately instead of jumping to the out label. Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Johannes Thumshirn <[email protected]> Acked-by: Sreekanth Reddy <[email protected]> Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-07-02scsi: iscsi: Change iSCSI workqueue max_active back to 1Bob Liu2-2/+2
Commit 3ce419662dd4 ("scsi: iscsi: Register sysfs for iscsi workqueue") enabled 'cpumask' support for iSCSI workqueues. However, it is unnecessary to set max_active = 2 since 'cpumask' can still be modified when max_active is 1. This patch sets max_active to 1 so as to keep the same behaviour as before. Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Mike Christie <[email protected]> Signed-off-by: Bob Liu <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-07-03Merge tag 'drm-misc-fixes-2020-07-02' of ↵Dave Airlie2-32/+27
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes * dma-buf: fix a use-after-free bug * sun4i: remove HPD polling Signed-off-by: Dave Airlie <[email protected]> From: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20200702075143.GA25040@linux-uq9g
2020-07-02hwmon: (pmbus) fix a typo in Kconfig SENSORS_IR35221 optionTao Ren1-1/+1
Fix a typo in SENSORS_IR35221 option: module name should be "ir35221" instead of "ir35521". Fixes: 8991ebd9c9a6 ("hwmon: (pmbus) Add client driver for IR35221") Cc: Samuel Mendoza-Jonas <[email protected]> Signed-off-by: Tao Ren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2020-07-02Merge tag 'block-5.8-2020-07-01' of git://git.kernel.dk/linux-blockLinus Torvalds1-0/+1
Pull block fixes from Jens Axboe: - Use kvfree_sensitive() for the block keyslot free (Eric) - Sync blk-mq debugfs flags (Hou) - Memory leak fix in virtio-blk error path (Hou) * tag 'block-5.8-2020-07-01' of git://git.kernel.dk/linux-block: virtio-blk: free vblk-vqs in error path of virtblk_probe() block/keyslot-manager: use kvfree_sensitive() blk-mq-debugfs: update blk_queue_flag_name[] accordingly for new flags
2020-07-02net: dsa: microchip: set the correct number of portsCodrin Ciubotariu2-0/+6
The number of ports is incorrectly set to the maximum available for a DSA switch. Even if the extra ports are not used, this causes some functions to be called later, like port_disable() and port_stp_state_set(). If the driver doesn't check the port index, it will end up modifying unknown registers. Fixes: b987e98e50ab ("dsa: add DSA switch driver for Microchip KSZ9477") Signed-off-by: Codrin Ciubotariu <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-02xen/xenbus: let xenbus_map_ring_valloc() return errno values onlyJuergen Gross1-16/+6
Today xenbus_map_ring_valloc() can return either a negative errno value (-ENOMEM or -EINVAL) or a grant status value. This is a mess as e.g -ENOMEM and GNTST_eagain have the same numeric value. Fix that by turning all grant mapping errors into -ENOENT. This is no problem as all callers of xenbus_map_ring_valloc() only use the return value to print an error message, and in case of mapping errors the grant status value has already been printed by __xenbus_map_ring() before. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Boris Ostrovsky <[email protected]>
2020-07-02xen/xenbus: avoid large structs and arrays on the stackJuergen Gross1-78/+83
xenbus_map_ring_valloc() and its sub-functions are putting quite large structs and arrays on the stack. This is problematic at runtime, but might also result in build failures (e.g. with clang due to the option -Werror,-Wframe-larger-than=... used). Fix that by moving most of the data from the stack into a dynamically allocated struct. Performance is no issue here, as xenbus_map_ring_valloc() is used only when adding a new PV device to a backend driver. While at it move some duplicated code from pv/hvm specific mapping functions to the single caller. Reported-by: Arnd Bergmann <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Boris Ostrovsky <[email protected]>
2020-07-02bus: ti-sysc: Do not disable on suspend for no-idleTony Lindgren1-2/+4
If we have "ti,no-idle" specified for a module we must not disable the the module on suspend to keep things backwards compatible. Fixes: 386cb76681ca ("bus: ti-sysc: Handle missed no-idle property in addition to no-idle-on-init") Reported-by: Grygorii Strashko <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2020-07-02IB/sa: Resolv use-after-free in ib_nl_make_request()Divya Indi1-21/+17
There is a race condition where ib_nl_make_request() inserts the request data into the linked list but the timer in ib_nl_request_timeout() can see it and destroy it before ib_nl_send_msg() is done touching it. This could happen, for instance, if there is a long delay allocating memory during nlmsg_new() This causes a use-after-free in the send_mad() thread: [<ffffffffa02f43cb>] ? ib_pack+0x17b/0x240 [ib_core] [ <ffffffffa032aef1>] ib_sa_path_rec_get+0x181/0x200 [ib_sa] [<ffffffffa0379db0>] rdma_resolve_route+0x3c0/0x8d0 [rdma_cm] [<ffffffffa0374450>] ? cma_bind_port+0xa0/0xa0 [rdma_cm] [<ffffffffa040f850>] ? rds_rdma_cm_event_handler_cmn+0x850/0x850 [rds_rdma] [<ffffffffa040f22c>] rds_rdma_cm_event_handler_cmn+0x22c/0x850 [rds_rdma] [<ffffffffa040f860>] rds_rdma_cm_event_handler+0x10/0x20 [rds_rdma] [<ffffffffa037778e>] addr_handler+0x9e/0x140 [rdma_cm] [<ffffffffa026cdb4>] process_req+0x134/0x190 [ib_addr] [<ffffffff810a02f9>] process_one_work+0x169/0x4a0 [<ffffffff810a0b2b>] worker_thread+0x5b/0x560 [<ffffffff810a0ad0>] ? flush_delayed_work+0x50/0x50 [<ffffffff810a68fb>] kthread+0xcb/0xf0 [<ffffffff816ec49a>] ? __schedule+0x24a/0x810 [<ffffffff816ec49a>] ? __schedule+0x24a/0x810 [<ffffffff810a6830>] ? kthread_create_on_node+0x180/0x180 [<ffffffff816f25a7>] ret_from_fork+0x47/0x90 [<ffffffff810a6830>] ? kthread_create_on_node+0x180/0x180 The ownership rule is once the request is on the list, ownership transfers to the list and the local thread can't touch it any more, just like for the normal MAD case in send_mad(). Thus, instead of adding before send and then trying to delete after on errors, move the entire thing under the spinlock so that the send and update of the lists are atomic to the conurrent threads. Lightly reoganize things so spinlock safe memory allocations are done in the final NL send path and the rest of the setup work is done before and outside the lock. Fixes: 3ebd2fd0d011 ("IB/sa: Put netlink request into the request list before sending") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Divya Indi <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-07-02bus: ti-sysc: Fix sleeping function called from invalid context for RTC quirkTony Lindgren1-2/+2
With CONFIG_DEBUG_ATOMIC_SLEEP enabled we can see the following with RTC probe: BUG: sleeping function called from invalid context at drivers/bus/ti-sysc.c:1736 ... (sysc_quirk_rtc) from [<c060d01c>] (sysc_write_sysconfig+0x1c/0x60) (sysc_write_sysconfig) from [<c060d9f4>] (sysc_enable_module+0x11c/0x274) (sysc_enable_module) from [<c060f37c>] (sysc_probe+0xe9c/0x1380) (sysc_probe) from [<c06e9384>] (platform_drv_probe+0x48/0x98) Fixes: e8639e1c986a ("bus: ti-sysc: Handle module unlock quirk needed for some RTC") Signed-off-by: Tony Lindgren <[email protected]>
2020-07-02bus: ti-sysc: Fix wakeirq sleeping function called from invalid contextTony Lindgren1-7/+6
With CONFIG_DEBUG_ATOMIC_SLEEP enabled we can see the following with wakeirqs and serial console idled: BUG: sleeping function called from invalid context at drivers/bus/ti-sysc.c:242 ... (sysc_wait_softreset) from [<c0606894>] (sysc_enable_module+0x48/0x274) (sysc_enable_module) from [<c0606c5c>] (sysc_runtime_resume+0x19c/0x1d8) (sysc_runtime_resume) from [<c0606cf0>] (sysc_child_runtime_resume+0x58/0x84) (sysc_child_runtime_resume) from [<c06eb7bc>] (__rpm_callback+0x30/0x12c) (__rpm_callback) from [<c06eb8d8>] (rpm_callback+0x20/0x80) (rpm_callback) from [<c06eb434>] (rpm_resume+0x638/0x7fc) (rpm_resume) from [<c06eb658>] (__pm_runtime_resume+0x60/0x9c) (__pm_runtime_resume) from [<c06edc08>] (handle_threaded_wake_irq+0x24/0x60) (handle_threaded_wake_irq) from [<c01befec>] (irq_thread_fn+0x1c/0x78) (irq_thread_fn) from [<c01bf30c>] (irq_thread+0x140/0x26c) We have __pm_runtime_resume() call the sysc_runtime_resume() with spinlock held and interrupts disabled. Fixes: d46f9fbec719 ("bus: ti-sysc: Use optional clocks on for enable and wait for softreset bit") Signed-off-by: Tony Lindgren <[email protected]>
2020-07-02IB/hfi1: Do not destroy link_wq when the device is shut downKaike Wan1-5/+5
The workqueue link_wq should only be destroyed when the hfi1 driver is unloaded, not when the device is shut down. Fixes: 71d47008ca1b ("IB/hfi1: Create workqueue for link events") Link: https://lore.kernel.org/r/[email protected] Cc: <[email protected]> Reviewed-by: Mike Marciniszyn <[email protected]> Signed-off-by: Kaike Wan <[email protected]> Signed-off-by: Dennis Dalessandro <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-07-02IB/hfi1: Do not destroy hfi1_wq when the device is shut downKaike Wan3-6/+31
The workqueue hfi1_wq is destroyed in function shutdown_device(), which is called by either shutdown_one() or remove_one(). The function shutdown_one() is called when the kernel is rebooted while remove_one() is called when the hfi1 driver is unloaded. When the kernel is rebooted, hfi1_wq is destroyed while all qps are still active, leading to a kernel crash: BUG: unable to handle kernel NULL pointer dereference at 0000000000000102 IP: [<ffffffff94cb7b02>] __queue_work+0x32/0x3e0 PGD 0 Oops: 0000 [#1] SMP Modules linked in: dm_round_robin nvme_rdma(OE) nvme_fabrics(OE) nvme_core(OE) ib_isert iscsi_target_mod target_core_mod ib_ucm mlx4_ib iTCO_wdt iTCO_vendor_support mxm_wmi sb_edac intel_powerclamp coretemp intel_rapl iosf_mbi kvm rpcrdma sunrpc irqbypass crc32_pclmul ghash_clmulni_intel rdma_ucm aesni_intel ib_uverbs lrw gf128mul opa_vnic glue_helper ablk_helper ib_iser cryptd ib_umad rdma_cm iw_cm ses enclosure libiscsi scsi_transport_sas pcspkr joydev ib_ipoib(OE) scsi_transport_iscsi ib_cm sg ipmi_ssif mei_me lpc_ich i2c_i801 mei ioatdma ipmi_si dm_multipath ipmi_devintf ipmi_msghandler wmi acpi_pad acpi_power_meter hangcheck_timer ip_tables ext4 mbcache jbd2 mlx4_en sd_mod crc_t10dif crct10dif_generic mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm hfi1(OE) crct10dif_pclmul crct10dif_common crc32c_intel drm ahci mlx4_core libahci rdmavt(OE) igb megaraid_sas ib_core libata drm_panel_orientation_quirks ptp pps_core devlink dca i2c_algo_bit dm_mirror dm_region_hash dm_log dm_mod CPU: 19 PID: 0 Comm: swapper/19 Kdump: loaded Tainted: G OE ------------ 3.10.0-957.el7.x86_64 #1 Hardware name: Phegda X2226A/S2600CW, BIOS SE5C610.86B.01.01.0024.021320181901 02/13/2018 task: ffff8a799ba0d140 ti: ffff8a799bad8000 task.ti: ffff8a799bad8000 RIP: 0010:[<ffffffff94cb7b02>] [<ffffffff94cb7b02>] __queue_work+0x32/0x3e0 RSP: 0018:ffff8a90dde43d80 EFLAGS: 00010046 RAX: 0000000000000082 RBX: 0000000000000086 RCX: 0000000000000000 RDX: ffff8a90b924fcb8 RSI: 0000000000000000 RDI: 000000000000001b RBP: ffff8a90dde43db8 R08: ffff8a799ba0d6d8 R09: ffff8a90dde53900 R10: 0000000000000002 R11: ffff8a90dde43de8 R12: ffff8a90b924fcb8 R13: 000000000000001b R14: 0000000000000000 R15: ffff8a90d2890000 FS: 0000000000000000(0000) GS:ffff8a90dde40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000102 CR3: 0000001a70410000 CR4: 00000000001607e0 Call Trace: [<ffffffff94cb8105>] queue_work_on+0x45/0x50 [<ffffffffc03f781e>] _hfi1_schedule_send+0x6e/0xc0 [hfi1] [<ffffffffc03f78a2>] hfi1_schedule_send+0x32/0x70 [hfi1] [<ffffffffc02cf2d9>] rvt_rc_timeout+0xe9/0x130 [rdmavt] [<ffffffff94ce563a>] ? trigger_load_balance+0x6a/0x280 [<ffffffffc02cf1f0>] ? rvt_free_qpn+0x40/0x40 [rdmavt] [<ffffffff94ca7f58>] call_timer_fn+0x38/0x110 [<ffffffffc02cf1f0>] ? rvt_free_qpn+0x40/0x40 [rdmavt] [<ffffffff94caa3bd>] run_timer_softirq+0x24d/0x300 [<ffffffff94ca0f05>] __do_softirq+0xf5/0x280 [<ffffffff9537832c>] call_softirq+0x1c/0x30 [<ffffffff94c2e675>] do_softirq+0x65/0xa0 [<ffffffff94ca1285>] irq_exit+0x105/0x110 [<ffffffff953796c8>] smp_apic_timer_interrupt+0x48/0x60 [<ffffffff95375df2>] apic_timer_interrupt+0x162/0x170 <EOI> [<ffffffff951adfb7>] ? cpuidle_enter_state+0x57/0xd0 [<ffffffff951ae10e>] cpuidle_idle_call+0xde/0x230 [<ffffffff94c366de>] arch_cpu_idle+0xe/0xc0 [<ffffffff94cfc3ba>] cpu_startup_entry+0x14a/0x1e0 [<ffffffff94c57db7>] start_secondary+0x1f7/0x270 [<ffffffff94c000d5>] start_cpu+0x5/0x14 The solution is to destroy the workqueue only when the hfi1 driver is unloaded, not when the device is shut down. In addition, when the device is shut down, no more work should be scheduled on the workqueues and the workqueues are flushed. Fixes: 8d3e71136a08 ("IB/{hfi1, qib}: Add handling of kernel restart") Link: https://lore.kernel.org/r/[email protected] Cc: <[email protected]> Reviewed-by: Mike Marciniszyn <[email protected]> Signed-off-by: Kaike Wan <[email protected]> Signed-off-by: Dennis Dalessandro <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-07-02tpm_tis: Remove the HID IFX0102Jarkko Sakkinen1-1/+0
Acer C720 running Linux v5.3 reports this in klog: tpm_tis: 1.2 TPM (device-id 0xB, rev-id 16) tpm tpm0: tpm_try_transmit: send(): error -5 tpm tpm0: A TPM error (-5) occurred attempting to determine the timeouts tpm_tis tpm_tis: Could not get TPM timeouts and durations tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16) tpm tpm0: tpm_try_transmit: send(): error -5 tpm tpm0: A TPM error (-5) occurred attempting to determine the timeouts tpm_tis 00:08: Could not get TPM timeouts and durations ima: No TPM chip found, activating TPM-bypass! tpm_inf_pnp 00:08: Found TPM with ID IFX0102 % git --no-pager grep IFX0102 drivers/char/tpm drivers/char/tpm/tpm_infineon.c: {"IFX0102", 0}, drivers/char/tpm/tpm_tis.c: {"IFX0102", 0}, /* Infineon */ Obviously IFX0102 was added to the HID table for the TCG TIS driver by mistake. Fixes: 93e1b7d42e1e ("[PATCH] tpm: add HID module parameter") Link: https://bugzilla.kernel.org/show_bug.cgi?id=203877 Cc: [email protected] Cc: Kylene Jo Hall <[email protected]> Reported-by: Ferry Toth: <[email protected]> Reviewed-by: Jerry Snitselaar <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-07-02tpm_tis_spi: Prefer async probeDouglas Anderson1-0/+1
On a Chromebook I'm working on I noticed a big (~1 second) delay during bootup where nothing was happening. Right around this big delay there were messages about the TPM: [ 2.311352] tpm_tis_spi spi0.0: TPM ready IRQ confirmed on attempt 2 [ 3.332790] tpm_tis_spi spi0.0: Cr50 firmware version: ... I put a few printouts in and saw that tpm_tis_spi_init() (specifically tpm_chip_register() in that function) was taking the lion's share of this time, though ~115 ms of the time was in cr50_print_fw_version(). Let's make a one-line change to prefer async probe for tpm_tis_spi. There's no reason we need to block other drivers from probing while we load. NOTES: * It's possible that other hardware runs through the init sequence faster than Cr50 and this isn't such a big problem for them. However, even if they are faster they are still doing _some_ transfers over a SPI bus so this should benefit everyone even if to a lesser extent. * It's possible that there are extra delays in the code that could be optimized out. I didn't dig since once I enabled async probe they no longer impacted me. Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-07-02tpm: ibmvtpm: Wait for ready buffer before probing for TPM2 attributesDavid Gibson1-7/+7
The tpm2_get_cc_attrs_tbl() call will result in TPM commands being issued, which will need the use of the internal command/response buffer. But, we're issuing this *before* we've waited to make sure that buffer is allocated. This can result in intermittent failures to probe if the hypervisor / TPM implementation doesn't respond quickly enough. I find it fails almost every time with an 8 vcpu guest under KVM with software emulated TPM. To fix it, just move the tpm2_get_cc_attrs_tlb() call after the existing code to wait for initialization, which will ensure the buffer is allocated. Fixes: 18b3670d79ae9 ("tpm: ibmvtpm: Add support for TPM2") Signed-off-by: David Gibson <[email protected]> Reviewed-by: Jerry Snitselaar <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-07-02tpm/st33zp24: fix spelling mistake "drescription" -> "description"Binbin Zhou3-4/+4
Trivial fix, the spelling of "drescription" is incorrect in function comment. Fix this. Signed-off-by: Binbin Zhou <[email protected]> Acked-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-07-02tpm_tis: extra chip->ops check on error path in tpm_tis_core_initVasily Averin1-1/+1
Found by smatch: drivers/char/tpm/tpm_tis_core.c:1088 tpm_tis_core_init() warn: variable dereferenced before check 'chip->ops' (see line 979) 'chip->ops' is assigned in the beginning of function in tpmm_chip_alloc->tpm_chip_alloc and is used before first possible goto to error path. Signed-off-by: Vasily Averin <[email protected]> Reviewed-by: Jerry Snitselaar <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-07-02tpm_tis_spi: Don't send anything during flow controlDouglas Anderson1-5/+4
During flow control we are just reading from the TPM, yet our spi_xfer has the tx_buf and rx_buf both non-NULL which means we're requesting a full duplex transfer. SPI is always somewhat of a full duplex protocol anyway and in theory the other side shouldn't really be looking at what we're sending it during flow control, but it's still a bit ugly to be sending some "random" data when we shouldn't. The default tpm_tis_spi_flow_control() tries to address this by setting 'phy->iobuf[0] = 0'. This partially avoids the problem of sending "random" data, but since our tx_buf and rx_buf both point to the same place I believe there is the potential of us sending the TPM's previous byte back to it if we hit the retry loop. Another flow control implementation, cr50_spi_flow_control(), doesn't address this at all. Let's clean this up and just make the tx_buf NULL before we call flow_control(). Not only does this ensure that we're not sending any "random" bytes but it also possibly could make the SPI controller behave in a slightly more optimal way. NOTE: no actual observed problems are fixed by this patch--it's was just made based on code inspection. Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Paul Menzel <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-07-02tpm: Fix TIS locality timeout problemsJames Bottomley1-10/+9
It has been reported that some TIS based TPMs are giving unexpected errors when using the O_NONBLOCK path of the TPM device. The problem is that some TPMs don't like it when you get and then relinquish a locality (as the tpm_try_get_ops()/tpm_put_ops() pair does) without sending a command. This currently happens all the time in the O_NONBLOCK write path. Fix this by moving the tpm_try_get_ops() further down the code to after the O_NONBLOCK determination is made. This is safe because the priv->buffer_mutex still protects the priv state being modified. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206275 Fixes: d23d12484307 ("tpm: fix invalid locking in NONBLOCKING mode") Reported-by: Mario Limonciello <[email protected]> Tested-by: Alex Guzman <[email protected]> Cc: [email protected] Reviewed-by: Jerry Snitselaar <[email protected]> Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2020-07-02RDMA/mlx5: Fix legacy IPoIB QP initializationLeon Romanovsky1-0/+4
Legacy IPoIB sets IB_QP_CREATE_NETIF_QP QP create flag and because mlx5 doesn't use this flag, the process_create_flags() failed to create IPoIB QPs. Fixes: 2978975ce7f1 ("RDMA/mlx5: Process create QP flags in one place") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-07-02IB/hfi1: Add explicit cast OPA_MTU_8192 to 'enum ib_mtu'Nathan Chancellor1-1/+1
Clang warns: drivers/infiniband/hw/hfi1/qp.c:198:9: warning: implicit conversion from enumeration type 'enum opa_mtu' to different enumeration type 'enum ib_mtu' [-Wenum-conversion] mtu = OPA_MTU_8192; ~ ^~~~~~~~~~~~ enum opa_mtu extends enum ib_mtu. There are typically two ways to deal with this: * Remove the expected types and just use 'int' for all parameters and types. * Explicitly cast the enums between each other. This driver chooses to do the later so do the same thing here. Fixes: 6d72344cf6c4 ("IB/ipoib: Increase ipoib Datagram mode MTU's upper limit") Link: https://lore.kernel.org/r/[email protected] Link: https://github.com/ClangBuiltLinux/linux/issues/1062 Link: https://lore.kernel.org/linux-rdma/20200527040350.GA3118979@ubuntu-s3-xlarge-x86/ Signed-off-by: Nathan Chancellor <[email protected]> Acked-by: Dennis Dalessandro <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-07-02dmaengine: idxd: fix misc interrupt handler thread unmaskingDave Jiang1-1/+2
Fix unmasking of misc interrupt handler when completing normal. It exits early and skips the unmasking with the current implementation. Fix to unmask interrupt when exiting normally. Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators") Signed-off-by: Dave Jiang <[email protected]> Link: https://lore.kernel.org/r/159311256528.855.11527922406329728512.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <[email protected]>
2020-07-02dmaengine: idxd: cleanup workqueue config after disablingDave Jiang3-0/+31
After disabling a device, we should clean up the internal state for the wqs and zero out the configuration registers. Without doing so can cause issues when the user reprogram the wqs. Fixes: c52ca478233c ("dmaengine: idxd: add configuration component of driver") Reported-by: Yixin Zhang <[email protected]> Signed-off-by: Dave Jiang <[email protected]> Tested-by: Yixin Zhang <[email protected]> Link: https://lore.kernel.org/r/159311264246.1198.11955791213681679428.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <[email protected]>
2020-07-02nvme: fix a crash in nvme_mpath_add_diskChristoph Hellwig1-3/+4
For private namespaces ns->head_disk is NULL, so add a NULL check before updating the BDI capabilities. Fixes: b2ce4d90690b ("nvme-multipath: set bdi capabilities once") Reported-by: Avinash M N <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Max Gurtovoy <[email protected]>
2020-07-02nvme: fix identify error status silent ignoreSagi Grimberg1-3/+9
Commit 59c7c3caaaf8 intended to only silently ignore non retry-able errors (DNR bit set) such that we can still identify misbehaving controllers, and in the other hand propagate retry-able errors (DNR bit cleared) so we don't wrongly abandon a namespace just because it happens to be temporarily inaccessible. The goal remains the same as the original commit where this was introduced but unfortunately had the logic backwards. Fixes: 59c7c3caaaf8 ("nvme: fix possible hang when ns scanning fails during error recovery") Reported-by: Keith Busch <[email protected]> Signed-off-by: Sagi Grimberg <[email protected]> Reviewed-by: Keith Busch <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2020-07-02drm/meson: viu: fix setting the OSD burst length in VIU_OSD1_FIFO_CTRL_STATMartin Blumenstingl2-9/+8
The burst length is configured in VIU_OSD1_FIFO_CTRL_STAT[31] and VIU_OSD1_FIFO_CTRL_STAT[11:10]. The public S905D3 datasheet describes this as: - 0x0 = up to 24 per burst - 0x1 = up to 32 per burst - 0x2 = up to 48 per burst - 0x3 = up to 64 per burst - 0x4 = up to 96 per burst - 0x5 = up to 128 per burst The lower two bits map to VIU_OSD1_FIFO_CTRL_STAT[11:10] while the upper bit maps to VIU_OSD1_FIFO_CTRL_STAT[31]. Replace meson_viu_osd_burst_length_reg() with pre-defined macros which set these values. meson_viu_osd_burst_length_reg() always returned 0 (for the two used values: 32 and 64 at least) and thus incorrectly set the burst size to 24. Fixes: 147ae1cbaa1842 ("drm: meson: viu: use proper macros instead of magic constants") Signed-off-by: Martin Blumenstingl <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Tested-by: Christian Hewitt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-07-02Merge tag 'amd-drm-fixes-5.8-2020-07-01' of ↵Dave Airlie4-10/+16
git://people.freedesktop.org/~agd5f/linux into drm-fixes amd-drm-fixes-5.8-2020-07-01: amdgpu: - Fix for vega20 boards without RAS support - DC bandwidth revalidation fix - Fix Renoir vram info fetching - Fix hwmon freq printing Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-07-02Merge tag 'drm-intel-fixes-2020-07-01' of ↵Dave Airlie7-15/+304
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes drm/i915 fixes for v5.8-rc4: - GVT fixes - Include asm sources for render cache clear batches Signed-off-by: Dave Airlie <[email protected]> From: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-07-01net: dsa: microchip: enable ksz9893 via i2c in the ksz9477 driverHelmut Grohne1-0/+1
The KSZ9893 3-Port Gigabit Ethernet Switch can be controlled via SPI, I²C or MDIO (very limited and not supported by this driver). While there is already a compatible entry for the SPI bus, it was missing for I²C. Signed-off-by: Helmut Grohne <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-01Merge tag 'hyperv-fixes-signed' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull hyperv fix from Wei Liu: "One patch from Joseph to make panic reporting contain more useful information" * tag 'hyperv-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: Drivers: hv: Change flag to write log level in panic msg to false
2020-07-01hinic: fix passing non negative value to ERR_PTRLuo bin1-0/+2
get_dev_cap and set_resources_state functions may return a positive value because of hardware failure, and the positive return value can not be passed to ERR_PTR directly. Fixes: 7dd29ee12865 ("hinic: add sriov feature support") Signed-off-by: Luo bin <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-01drm/amdgpu: use %u rather than %d for sclk/mclkAlex Deucher1-2/+2
Large clock values may overflow and show up as negative. Reported by prOMiNd on IRC. Acked-by: Nirmoy Das <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-07-01drm/amdgpu/atomfirmware: fix vram_info fetching for renoirAlex Deucher1-0/+1
Renoir uses integrated_system_info table v12. The table has the same layout as v11 with respect to this data. Just reuse the existing code for v12 for stable. Fixes incorrectly reported vram info in the driver output. Acked-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-07-01coresight: etmv4: Fix CPU power management setup in probe() functionMike Leach1-29/+53
The current probe() function calls a pair of cpuhp_xxx API functions to setup CPU hotplug handling. The hotplug lock is held for the duration of the two calls and other CPU related code using cpus_read_lock() / cpus_read_unlock() calls. The problem is that on error states, goto: statements bypass the cpus_read_unlock() call. This code has increased in complexity as the driver has developed. This patch introduces a pair of helper functions etm4_pm_setup_cpuslocked() and etm4_pm_clear() which correct the issues above and group the PM code a little better. The two functions etm4_cpu_pm_register() and etm4_cpu_pm_unregister() are dropped as these call cpu_pm_register_notifier() / ..unregister_notifier() dependent on CONFIG_CPU_PM - but this define is used to nop these functions out in the pm headers - so the wrapper functions are superfluous. Fixes: f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states") Fixes: e9f5d63f84fe ("hwtracing/coresight-etm4x: Use cpuhp_setup_state_nocalls_cpuslocked()") Fixes: 58eb457be028 ("hwtracing/coresight-etm4x: Convert to hotplug state machine") Signed-off-by: Mike Leach <[email protected]> Cc: stable <[email protected]> Reviewed-by: Mathieu Poirier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-01coresight: cti: Fix error handling in probeDan Carpenter1-42/+54
There were a couple problems with error handling in the probe function: 1) If the "drvdata" allocation failed then it lead to a NULL dereference. 2) On several error paths we decremented "nr_cti_cpu" before it was incremented which lead to a reference counting bug. There were also some parts of the error handling which were not bugs but were messy. The error handling was confusing to read. It printed some unnecessary error messages. The simplest way to fix these problems was to create a cti_pm_setup() function that did all the power management setup in one go. That way when we call cti_pm_release() we don't have to deal with the complications of a partially configured power management config. I reversed the "if (drvdata->ctidev.cpu >= 0)" condition in cti_pm_release() so that it mirros the new cti_pm_setup() function. Fixes: 6a0953ce7de9 ("coresight: cti: Add CPU idle pm notifer to CTI devices") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Mike Leach <[email protected]> Reviewed-by: Mathieu Poirier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-01Revert "zram: convert remaining CLASS_ATTR() to CLASS_ATTR_RO()"Wade Mealing1-1/+2
Turns out that the permissions for 0400 really are what we want here, otherwise any user can read from this file. [fixed formatting, added changelog, and made attribute static - gregkh] Reported-by: Wade Mealing <[email protected]> Cc: stable <[email protected]> Fixes: f40609d1591f ("zram: convert remaining CLASS_ATTR() to CLASS_ATTR_RO()") Link: https://bugzilla.redhat.com/show_bug.cgi?id=1847832 Reviewed-by: Steffen Maier <[email protected]> Acked-by: Minchan Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-01spi: mediatek: use correct SPI_CFG2_REG MACROleilk.liu1-7/+8
this patch use correct SPI_CFG2_REG offset. Signed-off-by: leilk.liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2020-07-01Merge tag 'thunderbolt-fix-for-v5.8-rc4' of ↵Greg Kroah-Hartman1-6/+6
git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-linus Mika writes: thunderbolt: Fix for v5.8-rc4 This includes a single patch that corrects path indices used in USB3 tunnel discovery. * tag 'thunderbolt-fix-for-v5.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Fix path indices used in USB3 tunnel discovery
2020-07-01Merge tag 'exynos-drm-fixes-for-v5.8-rc4' of ↵Dave Airlie3-4/+5
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes Two fixups - It fixes wrong return value by returing proper error value instead of fixed one. - It fixes ref count leak in mic_pre_enable. One cleanup - It removes dev_err() call on platform_get_irq() failure because platform_get_irq() call dev_err() itself on failure. Signed-off-by: Dave Airlie <[email protected]> From: Inki Dae <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-07-01Merge tag 'drm-msm-fixes-2020-06-25' of ↵Dave Airlie9-15/+21
https://gitlab.freedesktop.org/drm/msm into drm-fixes A few fixes, mostly fallout from the address space refactor and dpu color processing. Signed-off-by: Dave Airlie <[email protected]> From: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ <CAF6AEGv0SSXArdYs=mOLqJPJdkvk8CpxaJGecqgbOGazQ2n5og@mail.gmail.com
2020-06-30drm/amd/display: Only revalidate bandwidth on medium and fast updatesNicholas Kazlauskas1-4/+6
[Why] Changes that are fast don't require updating DLG parameters making this call unnecessary. Considering this is an expensive call it should not be done on every flip. DML touches clocks, p-state support, DLG params and a few other DC internal flags and these aren't expected during fast. A hang has been reported with this change when called on every flip which suggests that modifying these fields is not recommended behavior on fast updates. [How] Guard the validation to only happen if update type isn't FAST. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1191 Fixes: a24eaa5c51255b ("drm/amd/display: Revalidate bandwidth before commiting DC updates") Signed-off-by: Nicholas Kazlauskas <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-06-30virtio-blk: free vblk-vqs in error path of virtblk_probe()Hou Tao1-0/+1
Else there will be memory leak if alloc_disk() fails. Fixes: 6a27b656fc02 ("block: virtio-blk: support multi virt queues per virtio-blk device") Signed-off-by: Hou Tao <[email protected]> Reviewed-by: Stefano Garzarella <[email protected]> Reviewed-by: Ming Lei <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-06-30net: cxgb4: fix return error value in t4_prep_fwLi Heng1-4/+4
t4_prep_fw goto bye tag with positive return value when something bad happened and which can not free resource in adap_init0. so fix it to return negative value. Fixes: 16e47624e76b ("cxgb4: Add new scheme to update T4/T5 firmware") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Li Heng <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-30net: ipa: introduce ipa_cmd_tag_process()Alex Elder3-0/+25
Create a new function ipa_cmd_tag_process() that simply allocates a transaction, adds a tag process command to it to clear the hardware pipeline, and commits the transaction. Call it in from ipa_endpoint_suspend(), after suspending the modem endpoints but before suspending the AP command TX and AP LAN RX endpoints (which are used by the tag sequence). Signed-off-by: Alex Elder <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-30net: ipa: no checksum offload for SDM845 LAN RXAlex Elder1-1/+0
The AP LAN RX endpoint should not have download checksum offload enabled. The receive handler does properly accommodate the trailer that's added by the hardware, but we ignore it. Fixes: 1ed7d0c0fdba ("soc: qcom: ipa: configuration data") Signed-off-by: Alex Elder <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-30net: ipa: always check for stopped channelAlex Elder1-9/+7
In gsi_channel_stop(), there's a check to see if the channel might have entered STOPPED state since a previous call, which might have timed out before stopping completed. That check actually belongs in gsi_channel_stop_command(), which is called repeatedly by gsi_channel_stop() for RX channels. Fixes: 650d1603825d ("soc: qcom: ipa: the generic software interface") Signed-off-by: Alex Elder <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-30net: mvneta: fix use of state->speedRussell King1-1/+1
When support for short preambles was added, it incorrectly keyed its decision off state->speed instead of state->interface. state->speed is not guaranteed to be correct for in-band modes, which can lead to short preambles being unexpectedly disabled. Fix this by keying off the interface mode, which is the only way that mvneta can operate at 2.5Gbps. Fixes: da58a931f248 ("net: mvneta: Add support for 2500Mbps SGMII") Signed-off-by: Russell King <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-06-30tun: implement header_ops->parse_protocol for AF_PACKETJason A. Donenfeld1-0/+2
The tun driver passes up skb->protocol to userspace in the form of PI headers. For AF_PACKET injection, we need to support its call chain of: packet_sendmsg -> packet_snd -> packet_parse_headers -> dev_parse_header_protocol -> parse_protocol Without a valid parse_protocol, this returns zero, and the tun driver then gives userspace bogus values that it can't deal with. Note that this isn't the case with tap, because tap already benefits from the shared infrastructure for ethernet headers. But with tun, there's nothing. Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.