summaryrefslogtreecommitdiff
path: root/drivers/misc
AgeCommit message (Collapse)AuthorFilesLines
2021-04-09habanalabs: use correct define for 32-bit max valueOded Gabbay1-1/+1
Timeout in wait for interrupt is in 32-bit variable so we need to use the correct maximum value to compare. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
2021-04-09habanalabs: wait for interrupt supportOfir Bitton5-24/+285
In order to support command submissions from user space, the driver need to add support for user interrupt completions. The driver will allow multiple user threads to wait for an interrupt and perform a comparison with a given user address once interrupt expires. Signed-off-by: Ofir Bitton <obitton@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
2021-04-09habanalabs: enable all IRQs for user interrupt supportOfir Bitton3-2/+74
In order to support user interrupts, driver must enable all MSI-X interrupts for any case user will trigger them. We differentiate between a valid user interrupt and a non valid one. Signed-off-by: Ofir Bitton <obitton@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
2021-04-09habanalabs: reset device in case of sync errorOhad Sharabi5-0/+52
As the F/wW is the first to detect out of sync event, a new event is added to notify the driver on such event. In which case the driver performs hard reset. Signed-off-by: Ohad Sharabi <osharabi@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
2021-04-09habanalabs: change default CS timeout to 30 secondsOded Gabbay1-2/+2
Because our graph contains network operations, we need to account for delay in the network. 5 seconds timeout per CS is not enough to account for that. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
2021-04-09habanalabs: print if device is used on FD closeOded Gabbay2-4/+6
Notify to the user that although he closed the FD, the device is still in use because there are live CS and/or memory mappings (mmaps). Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
2021-04-09habanalabs: reset_upon_device_release is for bring-upOded Gabbay1-2/+1
Move the field to correct location in structure and remove comment. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
2021-04-09habanalabs: fail reset if device is not idleOded Gabbay1-14/+12
After any reset (soft or hard) the device (the engines/QMANs) should be idle. If they are not idle, fail the reset. If it is soft-reset, the driver will try to do hard-reset automatically. If it is hard-reset, the driver will make the device non-operational. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
2021-04-09habanalabs: reset after device is actually releasedOded Gabbay1-16/+16
The device is actually released only after the refcnt of the hpriv structure is 0, which means all its contexts were closed. If we reset the device while a context is still open, there are possibilities for unexpected behavior and crashes. For example, if the process has a mapping of a register block that is now currently being reset, and the process writes/reads to that block during the reset, the device can get stuck. Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
2021-04-09habanalabs: add reset support when user closes FDOfir Bitton2-2/+20
In order to support command submissions that are done directly from user space, the driver must perform soft reset once user closes its FD. In case the soft reset fails or device is not idle, a hard reset should be performed. Signed-off-by: Ofir Bitton <obitton@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
2021-04-09habanalabs: set max asid to 2farah kassabri2-2/+2
currently we support only 2 asids in all asics. asid 0 for driver, and asic 1 for user. no need to setup 1024 asids configurations at init phase. Signed-off-by: farah kassabri <fkassabri@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
2021-04-09lkdtm: use function_nocfiSami Tolvanen1-1/+1
To ensure we take the actual address of a function in kernel text, use function_nocfi. Otherwise, with CONFIG_CFI_CLANG, the compiler replaces the address with a pointer to the CFI jump table, which is actually in the module when compiled with CONFIG_LKDTM=m. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Acked-by: Kees Cook <keescook@chromium.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210408182843.1754385-11-samitolvanen@google.com
2021-04-09treewide: Change list_sort to use const pointersSami Tolvanen1-2/+2
list_sort() internally casts the comparison function passed to it to a different type with constant struct list_head pointers, and uses this pointer to call the functions, which trips indirect call Control-Flow Integrity (CFI) checking. Instead of removing the consts, this change defines the list_cmp_func_t type and changes the comparison function types of all list_sort() callers to use const pointers, thus avoiding type mismatches. Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210408182843.1754385-10-samitolvanen@google.com
2021-04-08lkdtm: Add REPORT_STACK for checking stack offsetsKees Cook3-0/+19
For validating the stack offset behavior, report the offset from a given process's first seen stack address. Add s script to calculate the results to the LKDTM kselftests. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20210401232347.2791257-7-keescook@chromium.org
2021-04-07uacce: Enable IOMMU_DEV_FEAT_IOPFJean-Philippe Brucker1-9/+30
The IOPF (I/O Page Fault) feature is now enabled independently from the SVA feature, because some IOPF implementations are device-specific and do not require IOMMU support for PCIe PRI or Arm SMMU stall. Enable IOPF unconditionally when enabling SVA for now. In the future, if a device driver implementing a uacce interface doesn't need IOPF support, it will need to tell the uacce module, for example with a new flag. Acked-by: Zhangfei Gao <zhangfei.gao@linaro.org> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Link: https://lore.kernel.org/r/20210401154718.307519-6-jean-philippe@linaro.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-04-05misc: Add Synopsys DesignWare xData IP driverGustavo Pimentel3-0/+431
Add Synopsys DesignWare xData IP driver. This driver enables/disables the PCI traffic generator module pertain to the Synopsys DesignWare prototype. Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Link: https://lore.kernel.org/r/daa1efe23850e77d6807dc3f371728fc0b7548b8.1617016509.git.gustavo.pimentel@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-05misc: vmw_vmci: explicitly initialize vmci_datagram payloadTetsuo Handa1-1/+1
KMSAN complains that vmci_check_host_caps() left the payload part of check_msg uninitialized. ===================================================== BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10 CPU: 1 PID: 1 Comm: swapper/0 Tainted: G B 5.11.0-rc7+ #4 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 Call Trace: dump_stack+0x21c/0x280 kmsan_report+0xfb/0x1e0 kmsan_internal_check_memory+0x202/0x520 kmsan_check_memory+0xd/0x10 iowrite8_rep+0x86/0x380 vmci_guest_probe_device+0xf0b/0x1e70 pci_device_probe+0xab3/0xe70 really_probe+0xd16/0x24d0 driver_probe_device+0x29d/0x3a0 device_driver_attach+0x25a/0x490 __driver_attach+0x78c/0x840 bus_for_each_dev+0x210/0x340 driver_attach+0x89/0xb0 bus_add_driver+0x677/0xc40 driver_register+0x485/0x8e0 __pci_register_driver+0x1ff/0x350 vmci_guest_init+0x3e/0x41 vmci_drv_init+0x1d6/0x43f do_one_initcall+0x39c/0x9a0 do_initcall_level+0x1d7/0x259 do_initcalls+0x127/0x1cb do_basic_setup+0x33/0x36 kernel_init_freeable+0x29a/0x3ed kernel_init+0x1f/0x840 ret_from_fork+0x1f/0x30 Uninit was created at: kmsan_internal_poison_shadow+0x5c/0xf0 kmsan_slab_alloc+0x8d/0xe0 kmem_cache_alloc+0x84f/0xe30 vmci_guest_probe_device+0xd11/0x1e70 pci_device_probe+0xab3/0xe70 really_probe+0xd16/0x24d0 driver_probe_device+0x29d/0x3a0 device_driver_attach+0x25a/0x490 __driver_attach+0x78c/0x840 bus_for_each_dev+0x210/0x340 driver_attach+0x89/0xb0 bus_add_driver+0x677/0xc40 driver_register+0x485/0x8e0 __pci_register_driver+0x1ff/0x350 vmci_guest_init+0x3e/0x41 vmci_drv_init+0x1d6/0x43f do_one_initcall+0x39c/0x9a0 do_initcall_level+0x1d7/0x259 do_initcalls+0x127/0x1cb do_basic_setup+0x33/0x36 kernel_init_freeable+0x29a/0x3ed kernel_init+0x1f/0x840 ret_from_fork+0x1f/0x30 Bytes 28-31 of 36 are uninitialized Memory access of size 36 starts at ffff8881675e5f00 ===================================================== Fixes: 1f166439917b69d3 ("VMCI: guest side driver implementation.") Cc: <stable@vger.kernel.org> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Link: https://lore.kernel.org/r/20210402121742.3917-2-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-05misc: vmw_vmci: explicitly initialize vmci_notify_bm_set_msg structTetsuo Handa1-1/+1
KMSAN complains that the vmci_use_ppn64() == false path in vmci_dbell_register_notification_bitmap() left upper 32bits of bitmap_set_msg.bitmap_ppn64 member uninitialized. ===================================================== BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc7+ #4 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 Call Trace: dump_stack+0x21c/0x280 kmsan_report+0xfb/0x1e0 kmsan_internal_check_memory+0x484/0x520 kmsan_check_memory+0xd/0x10 iowrite8_rep+0x86/0x380 vmci_send_datagram+0x150/0x280 vmci_dbell_register_notification_bitmap+0x133/0x1e0 vmci_guest_probe_device+0xcab/0x1e70 pci_device_probe+0xab3/0xe70 really_probe+0xd16/0x24d0 driver_probe_device+0x29d/0x3a0 device_driver_attach+0x25a/0x490 __driver_attach+0x78c/0x840 bus_for_each_dev+0x210/0x340 driver_attach+0x89/0xb0 bus_add_driver+0x677/0xc40 driver_register+0x485/0x8e0 __pci_register_driver+0x1ff/0x350 vmci_guest_init+0x3e/0x41 vmci_drv_init+0x1d6/0x43f do_one_initcall+0x39c/0x9a0 do_initcall_level+0x1d7/0x259 do_initcalls+0x127/0x1cb do_basic_setup+0x33/0x36 kernel_init_freeable+0x29a/0x3ed kernel_init+0x1f/0x840 ret_from_fork+0x1f/0x30 Local variable ----bitmap_set_msg@vmci_dbell_register_notification_bitmap created at: vmci_dbell_register_notification_bitmap+0x50/0x1e0 vmci_dbell_register_notification_bitmap+0x50/0x1e0 Bytes 28-31 of 32 are uninitialized Memory access of size 32 starts at ffff88810098f570 ===================================================== Fixes: 83e2ec765be03e8a ("VMCI: doorbell implementation.") Cc: <stable@vger.kernel.org> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Link: https://lore.kernel.org/r/20210402121742.3917-1-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-05Merge 5.12-rc6 into tty-nextGreg Kroah-Hartman1-10/+7
We need the serial/tty fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-05Merge 5.12-rc6 into char-misc-nextGreg Kroah-Hartman1-10/+7
We need the char/misc fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-02misc/pvpanic: Make some symbols staticYueHaibing1-2/+2
Fix sparse warnings: drivers/misc/pvpanic/pvpanic.c:28:18: warning: symbol 'pvpanic_list' was not declared. Should it be static? drivers/misc/pvpanic/pvpanic.c:29:12: warning: symbol 'pvpanic_lock' was not declared. Should it be static? Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20210331121706.15268-1-yuehaibing@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-02misc/pvpanic: fix return value check in pvpanic_pci_probe()Qiheng Lin1-2/+2
In case of error, the function pci_iomap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Qiheng Lin <linqiheng@huawei.com> Link: https://lore.kernel.org/r/20210330013659.916-1-linqiheng@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-28misc/pvpanic: add PCI driverMihai Carabas3-0/+134
Add support for pvpanic PCI device added in qemu [1]. At probe time, obtain the address where to read/write pvpanic events and pass it to the generic handling code. Will follow the same logic as pvpanic MMIO device driver. At remove time, unmap base address and disable PCI device. [1] https://github.com/qemu/qemu/commit/9df52f58e76e904fb141b10318362d718f470db2 Signed-off-by: Mihai Carabas <mihai.carabas@oracle.com> Link: https://lore.kernel.org/r/1616597356-20696-4-git-send-email-mihai.carabas@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-28misc/pvpanic: probe multiple instancesMihai Carabas3-39/+87
Create the mecahism that allows multiple pvpanic instances to call pvpanic_probe and receive panic events. A global list will retain all the mapped addresses where to write panic events. Signed-off-by: Mihai Carabas <mihai.carabas@oracle.com> Link: https://lore.kernel.org/r/1616597356-20696-3-git-send-email-mihai.carabas@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-28misc/pvpanic: split-up generic and platform dependent codeMihai Carabas7-51/+139
Split-up generic and platform dependent code in order to be able to re-use generic event handling code in pvpanic PCI device driver in the next patches. The code from pvpanic.c was split in two new files: - pvpanic.c: generic code that handles pvpanic events - pvpanic-mmio.c: platform/bus dependent code Signed-off-by: Mihai Carabas <mihai.carabas@oracle.com> Link: https://lore.kernel.org/r/1616597356-20696-2-git-send-email-mihai.carabas@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-28uacce: delete unneeded variable initializationKai Ye1-1/+1
delete unneeded variable initialization. Signed-off-by: Kai Ye <yekai13@huawei.com> Link: https://lore.kernel.org/r/1616749747-3882-1-git-send-email-yekai13@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-28kgdbts: Switch to do_sys_openat2() for breakpoint testingDaniel Thompson1-19/+29
Currently kgdbts can get stuck waiting for do_sys_open() to be called in some of the current tests. This is because C compilers often automatically inline this function, which is a very thin wrapper around do_sys_openat2(), into some of its callers. gcc-10 does this on (at least) both x86 and arm64. We can fix the test suite by placing the breakpoints on do_sys_openat2() instead since that isn't (currently) inlined. However do_sys_openat2() is a static function so we cannot simply use an addressof. Since we are testing debug machinery it is acceptable to use kallsyms to lookup a suitable address because this is more or less what kdb does in the same circumstances. Re-implement lookup_addr() to be based on kallsyms rather than function pointers. Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Link: https://lore.kernel.org/r/20210325094807.3546702-1-daniel.thompson@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-28misc: genwqe: Rudimentary typo fixesBhaskar Chowdhury1-5/+5
s/requsted/requested/ s/equests/requests/ s/occured/occurred/ s/conditon/condition/ s/emtpy/empty/ Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Link: https://lore.kernel.org/r/20210325015513.9373-1-unixbhaskar@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-28misc: sgi-xp: xp_main: make some symbols staticZou Wei1-2/+2
The sparse tool complains as follows: drivers/misc/sgi-xp/xp_main.c:24:22: warning: symbol 'xp_dbg_name' was not declared. Should it be static? drivers/misc/sgi-xp/xp_main.c:28:15: warning: symbol 'xp_dbg_subname' was not declared. Should it be static? These symbols are not used outside of xp_main.c, so this commit marks them static. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Link: https://lore.kernel.org/r/20210324084823.7393-1-zou_wei@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-24vmci_host: print unexpanded names of ioctl requests in debug messagesGleb Fotengauer-Malinovskiy1-1/+1
__stringify macro function expands its arguments, but in this messages we expect to see ioctl request name instead of it's _IOC macro expansion. $ cat stringify.c #include <stdio.h> #include <asm/ioctl.h> #define __stringify_1(x) #x #define __stringify(x) __stringify_1(x) #define VMCI_DO_IOCTL(ioctl_name) \ char *name = __stringify(IOCTL_VMCI_ ## ioctl_name); int main() { VMCI_DO_IOCTL(INIT_CONTEXT) printf("%s\n", name); } $ cc stringify.c $ ./a.out (((0U) << (((0+8)+8)+14)) | (((7)) << (0+8)) | (((0xa0)) << 0) | ((0) << ((0+8)+8))) Signed-off-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org> Link: https://lore.kernel.org/r/20210302153346.300416-1-glebfm@altlinux.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-24misc/sgi-xp: use NULL instead of using plain integer as pointerYang Li1-1/+1
This fixes the following sparse warnings: drivers/misc/sgi-xp/xpc_main.c:210:23: warning: Using plain integer as NULL pointer Reported-by: Abaci Robot <abaci@linux.alibaba.com> Reviewed-by: Steve Wahl <steve.wahl@hpe.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/1615885041-68750-1-git-send-email-yang.lee@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-24cxl: don't manipulate the mm.mm_users field directlyLaurent Dufour1-1/+1
It is better to rely on the API provided by the MM layer instead of directly manipulating the mm_users field. Acked-by: Frederic Barrat <fbarrat@linux.ibm.com> Acked-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com> Link: https://lore.kernel.org/r/20210310174405.51044-1-ldufour@linux.ibm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-24cxl: Fix couple of spellingsBhaskar Chowdhury1-1/+1
s/filesytem/filesystem/ s/symantics/semantics/ Acked-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Link: https://lore.kernel.org/r/20210322023307.168754-1-unixbhaskar@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-24misc: lis3lv02d: Do not log an error when kmalloc failsHans de Goede1-3/+1
Logging an error when kmalloc fails is not necessary (and in general should be avoided) because the malloc failure will already complain loudly itself. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210217102501.31758-3-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-24misc: lis3lv02d: Change lis3lv02d_init_device() return value for unknown ↵Hans de Goede1-1/+1
sensors to -ENODEV Modern HP laptops do not necessarily actually contain a lis3lv02d sensor, yet they still define a HPQ6007 device in there ACPI tables. This leads to the following messages being logged in dmesg: [ 17.376342] hp_accel: laptop model unknown, using default axes configuration [ 17.399766] lis3lv02d: unknown sensor type 0x0 [ 17.399804] hp_accel: probe of HPQ6007:00 failed with error -22 The third message is unnecessary and does not provide any useful info, change the return value for unknown sensors to -ENODEV. This is the proper return value to indicate that the driver will not be handling the device and it silences the pr_warn printing the third message. Signed-off-by: Hans de Goede <hdegoede@redhat.com> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199715 Link: https://lore.kernel.org/r/20210217102501.31758-2-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-24misc: lis3lv02d: Fix false-positive WARN on various HP modelsHans de Goede1-5/+16
Before this commit lis3lv02d_get_pwron_wait() had a WARN_ONCE() to catch a potential divide by 0. WARN macros should only be used to catch internal kernel bugs and that is not the case here. We have been receiving a lot of bug reports about kernel backtraces caused by this WARN. The div value being checked comes from the lis3->odrs[] array. Which is sized to be a power-of-2 matching the number of bits in lis3->odr_mask. The only lis3 model where this array is not entirely filled with non zero values. IOW the only model where we can hit the div == 0 check is the 3dc ("8 bits 3DC sensor") model: int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 5000}; Note the 0 value at index 0, according to the datasheet an odr index of 0 means "Power-down mode". HP typically uses a lis3 accelerometer for HDD fall protection. What I believe is happening here is that on newer HP devices, which only contain a SDD, the BIOS is leaving the lis3 device powered-down since it is not used for HDD fall protection. Note that the lis3_3dc_rates array initializer only specifies 10 values, which matches the datasheet. So it also contains 6 zero values at the end. Replace the WARN with a normal check, which treats an odr index of 0 as power-down and uses a normal dev_err() to report the error in case odr index point past the initialized part of the array. Fixes: 1510dd5954be ("lis3lv02d: avoid divide by zero due to unchecked") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=785814 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1817027 BugLink: https://bugs.centos.org/view.php?id=10720 Link: https://lore.kernel.org/r/20210217102501.31758-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-24kgdb: fix gcc-11 warning on indentationArnd Bergmann1-13/+13
gcc-11 starts warning about misleading indentation inside of macros: drivers/misc/kgdbts.c: In function ‘kgdbts_break_test’: drivers/misc/kgdbts.c:103:9: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation] 103 | if (verbose > 1) \ | ^~ drivers/misc/kgdbts.c:200:9: note: in expansion of macro ‘v2printk’ 200 | v2printk("kgdbts: breakpoint complete\n"); | ^~~~~~~~ drivers/misc/kgdbts.c:105:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ 105 | touch_nmi_watchdog(); \ | ^~~~~~~~~~~~~~~~~~ The code looks correct to me, so just reindent it for readability. Fixes: e8d31c204e36 ("kgdb: add kgdb internal test suite") Acked-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20210322164308.827846-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23mei: allow map and unmap of client dma buffer only for disconnected clientTomas Winkler1-10/+7
Allow map and unmap of the client dma buffer only when the client is not connected. The functions return -EPROTO if the client is already connected. This is to fix the race when traffic may start or stop when buffer is not available. Cc: <stable@vger.kernel.org> #v5.11+ Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Link: https://lore.kernel.org/r/20210318055959.305627-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-15Merge 5.12-rc3 into tty-nextGreg Kroah-Hartman9-27/+82
Resolves a merge issue with: drivers/tty/hvc/hvcs.c and we want the tty/serial fixes from 5.12-rc3 in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-15Merge v5.12-rc3 into char-misc-nextGreg Kroah-Hartman7-21/+81
We need the char/misc fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-13Merge tag 'char-misc-5.12-rc3' of ↵Linus Torvalds8-24/+81
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver fixes from Greg KH: "Here are some small misc/char driver fixes to resolve some reported problems: - habanalabs driver fixes - Acrn build fixes (reported many times) - pvpanic module table export fix All of these have been in linux-next for a while with no reported issues" * tag 'char-misc-5.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: misc/pvpanic: Export module FDT device table misc: fastrpc: restrict user apps from sending kernel RPC messages virt: acrn: Correct type casting of argument of copy_from_user() virt: acrn: Use EPOLLIN instead of POLLIN virt: acrn: Use vfs_poll() instead of f_op->poll() virt: acrn: Make remove_cpu sysfs invisible with !CONFIG_HOTPLUG_CPU cpu/hotplug: Fix build error of using {add,remove}_cpu() with !CONFIG_SMP habanalabs: fix debugfs address translation habanalabs: Disable file operations after device is removed habanalabs: Call put_pid() when releasing control device drivers: habanalabs: remove unused dentry pointer for debugfs files habanalabs: mark hl_eq_inc_ptr() as static
2021-03-10misc/pvpanic: Export module FDT device tableShile Zhang1-0/+1
Export the module FDT device table to ensure the FDT compatible strings are listed in the module alias. This help the pvpanic driver can be loaded on boot automatically not only the ACPI device, but also the FDT device. Fixes: 46f934c9a12fc ("misc/pvpanic: add support to get pvpanic device info FDT") Signed-off-by: Shile Zhang <shile.zhang@linux.alibaba.com> Link: https://lore.kernel.org/r/20210218123116.207751-1-shile.zhang@linux.alibaba.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-10misc: fastrpc: restrict user apps from sending kernel RPC messagesDmitry Baryshkov1-0/+5
Verify that user applications are not using the kernel RPC message handle to restrict them from directly attaching to guest OS on the remote subsystem. This is a port of CVE-2019-2308 fix. Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Jonathan Marek <jonathan@marek.ca> Cc: stable@vger.kernel.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210212192658.3476137-1-dmitry.baryshkov@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-10tty: remove TTY_LDISC_MAGICJiri Slaby1-1/+0
First, it is never checked. Second, use of it as a debugging aid is at least questionable. With the current tools, I don't think anyone used this kind of thing for debugging purposes for years. On the top of that, e.g. serdev does not set this field of tty_ldisc_ops at all. So get rid of this legacy. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20210302062214.29627-8-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-10drivers: misc: ad525x_dpot: Add missing check in dpot_read_spiDinghao Liu1-0/+3
The use of dpot_read_r8d8() after checking dpot->uid is similar. However, we check the return value and return an error code only in one path, which is odd. Link: https://lore.kernel.org/r/20210301125057.28819-1-dinghao.liu@zju.edu.cn Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-10drivers: habanalabs: remove unused dentry pointer for debugfs filesGreg Kroah-Hartman2-6/+1
The dentry for the created debugfs file was being saved, but never used anywhere. As the pointer isn't needed for anything, and the debugfs files are being properly removed by removing the parent directory, remove the saved pointer as well, saving a tiny bit of memory and logic. Cc: Oded Gabbay <ogabbay@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Tomer Tayar <ttayar@habana.ai> Cc: Moti Haimovski <mhaimovski@habana.ai> Cc: Omer Shpigelman <oshpigelman@habana.ai> Cc: Ofir Bitton <obitton@habana.ai> Cc: linux-kernel@vger.kernel.org Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20210216150828.3855810-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-10drivers: vmw_balloon: remove dentry pointer for debugfsGreg Kroah-Hartman1-8/+3
There is no need to keep the dentry pointer around for the created debugfs file, as it is only needed when removing it from the system. When it is to be removed, ask debugfs itself for the pointer, to save on storage and make things a bit simpler. Cc: Nadav Amit <namit@vmware.com> Cc: "VMware, Inc." <pv-drivers@vmware.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: linux-kernel@vger.kernel.org Acked-by: Nadav Amit <namit@vmware.com> Link: https://lore.kernel.org/r/20210216151209.3954129-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-10habanalabs: fix debugfs address translationfarah kassabri1-12/+26
when user uses virtual addresses to access dram through debugfs, driver translate this address to physical and use it for the access through the pcie bar. in case dram page size is different than the dmmu page size, we need to have special treatment for adding the page offset to the actual address, which is to use the dram page size mask to fetch the page offset from the virtual address, instead of the dmmu last hop shift. Signed-off-by: farah kassabri <fkassabri@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
2021-03-10habanalabs: Disable file operations after device is removedTomer Tayar2-6/+46
A device can be removed from the PCI subsystem while a process holds the file descriptor opened. In such a case, the driver attempts to kill the process, but as it is still possible that the process will be alive after this step, the device removal will complete, and we will end up with a process object that points to a device object which was already released. To prevent the usage of this released device object, disable the following file operations for this process object, and avoid the cleanup steps when the file descriptor is eventually closed. The latter is just a best effort, as memory leak will occur. Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
2021-03-10habanalabs: Call put_pid() when releasing control deviceTomer Tayar1-0/+2
The refcount of the "hl_fpriv" structure is not used for the control device, and thus hl_hpriv_put() is not called when releasing this device. This results with no call to put_pid(), so add it explicitly in hl_device_release_ctrl(). Signed-off-by: Tomer Tayar <ttayar@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-09-20 04:25:10 +0300