summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-10-29gpio: mlxbf2: Introduce IRQ supportAsmaa Mnebhi
Introduce standard IRQ handling in the gpio-mlxbf2.c driver. Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
2021-10-29iavf: Fix kernel BUG in free_msi_irqsPrzemyslaw Patynowski
Fix driver not freeing VF's traffic irqs, prior to calling pci_disable_msix in iavf_remove. There were possible 2 erroneous states in which, iavf_close would not be called. One erroneous state is fixed by allowing netdev to register, when state is already running. It was possible for VF adapter to enter state loop from running to resetting, where iavf_open would subsequently fail. If user would then unload driver/remove VF pci, iavf_close would not be called, as the netdev was not registered, leaving traffic pcis still allocated. Fixed this by breaking loop, allowing netdev to open device when adapter state is __IAVF_RUNNING and it is not explicitily downed. Other possiblity is entering to iavf_remove from __IAVF_RESETTING state, where iavf_close would not free irqs, but just return 0. Fixed this by checking for last adapter state and then removing irqs. Kernel panic: [ 2773.628585] kernel BUG at drivers/pci/msi.c:375! ... [ 2773.631567] RIP: 0010:free_msi_irqs+0x180/0x1b0 ... [ 2773.640939] Call Trace: [ 2773.641572] pci_disable_msix+0xf7/0x120 [ 2773.642224] iavf_reset_interrupt_capability.part.41+0x15/0x30 [iavf] [ 2773.642897] iavf_remove+0x12e/0x500 [iavf] [ 2773.643578] pci_device_remove+0x3b/0xc0 [ 2773.644266] device_release_driver_internal+0x103/0x1f0 [ 2773.644948] pci_stop_bus_device+0x69/0x90 [ 2773.645576] pci_stop_and_remove_bus_device+0xe/0x20 [ 2773.646215] pci_iov_remove_virtfn+0xba/0x120 [ 2773.646862] sriov_disable+0x2f/0xe0 [ 2773.647531] ice_free_vfs+0x2f8/0x350 [ice] [ 2773.648207] ice_sriov_configure+0x94/0x960 [ice] [ 2773.648883] ? _kstrtoull+0x3b/0x90 [ 2773.649560] sriov_numvfs_store+0x10a/0x190 [ 2773.650249] kernfs_fop_write+0x116/0x190 [ 2773.650948] vfs_write+0xa5/0x1a0 [ 2773.651651] ksys_write+0x4f/0xb0 [ 2773.652358] do_syscall_64+0x5b/0x1a0 [ 2773.653075] entry_SYSCALL_64_after_hwframe+0x65/0xca Fixes: 22ead37f8af8 ("i40evf: Add longer wait after remove module") Signed-off-by: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com> Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-10-29iavf: Add helper function to go from pci_dev to adapterKaren Sornek
Add helper function to go from pci_dev to adapter to make work simple - to go from a pci_dev to the adapter structure and make netdev assignment instead of having to go to the net_device then the adapter. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Signed-off-by: Karen Sornek <karen.sornek@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-10-29virtchnl: Use the BIT() macro for capability/offload flagsBrett Creeley
Currently raw hex values are used to define specific bits for each capability/offload in virtchnl.h. Using raw hex values makes it unclear which bits are used/available. Fix this by using the BIT() macro so it's immediately obvious which bits are used/available. Also, move the VIRTCHNL_VF_CAP_ADV_LINK_SPEED define in the correct place to line up with the other bit values and add a comment for its purpose. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Tony Brelinski <tony.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-10-29virtchnl: Remove unused VIRTCHNL_VF_OFFLOAD_RSVD defineBrett Creeley
Remove unused define that is currently marked as reserved. This will open up space for a new feature if/when it's introduced. Also, there is no reason to keep unused defines around. Suggested-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Tony Brelinski <tony.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-10-29i2c: xlr: Fix a resource leak in the error handling path of 'xlr_i2c_probe()'Christophe JAILLET
A successful 'clk_prepare()' call should be balanced by a corresponding 'clk_unprepare()' call in the error handling path of the probe, as already done in the remove function. More specifically, 'clk_prepare_enable()' is used, but 'clk_disable()' is also already called. So just the unprepare step has still to be done. Update the error handling path accordingly. Fixes: 75d31c2372e4 ("i2c: xlr: add support for Sigma Designs controller variant") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2021-10-29i2c: qup: move to use request_irq by IRQF_NO_AUTOEN flagTian Tao
disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable because of requesting. Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2021-10-29i2c: qup: fix a trivial typoRandy Dunlap
Correct the typo of "reamining" to "remaining". Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Suggested-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2021-10-29i2c: tegra: Ensure that device is suspended before driver is removedDmitry Osipenko
Tegra I2C device isn't guaranteed to be suspended after removal of the driver since driver uses pm_runtime_put() that is asynchronous and pm_runtime_disable() cancels pending power-change requests. This means that potentially refcount of the clocks may become unbalanced after removal of the driver. This a very minor problem which unlikely to happen in practice and won't cause any visible problems, nevertheless let's replace pm_runtime_disable() with pm_runtime_force_suspend() and use pm_runtime_put_sync() which disables RPM of the device and puts it into suspend before driver is removed. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2021-10-29Merge tag 'at24-updates-for-v5.16' of ↵Wolfram Sang
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into i2c/for-mergewindow at24 updates for v5.16 - add two new compatible entries to the DT bindings
2021-10-29signal: Replace force_sigsegv(SIGSEGV) with force_fatal_sig(SIGSEGV)Eric W. Biederman
Now that force_fatal_sig exists it is unnecessary and a bit confusing to use force_sigsegv in cases where the simpler force_fatal_sig is wanted. So change every instance we can to make the code clearer. Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Link: https://lkml.kernel.org/r/877de7jrev.fsf@disp2133 Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2021-10-29exit/r8188eu: Replace the macro thread_exit with a simple return 0Eric W. Biederman
The macro thread_exit is called is at the end of functions started with kthread_run. The code in kthread_run has arranged things so a kernel thread can just return and do_exit will be called. So just have rtw_cmd_thread and mp_xmit_packet_thread return instead of calling complete_and_exit. Link: https://lkml.kernel.org/r/20211020174406.17889-20-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2021-10-29exit/rtl8712: Replace the macro thread_exit with a simple return 0Eric W. Biederman
The macro thread_exit is called is at the end of a function started with kthread_run. The code in kthread_run has arranged things so a kernel thread can just return and do_exit will be called. So just have the cmd_thread return instead of calling complete_and_exit. Link: https://lkml.kernel.org/r/20211020174406.17889-19-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2021-10-29exit/rtl8723bs: Replace the macro thread_exit with a simple return 0Eric W. Biederman
Every place thread_exit is called is at the end of a function started with kthread_run. The code in kthread_run has arranged things so a kernel thread can just return and do_exit will be called. So just have the threads return instead of calling complete_and_exit. Link: https://lkml.kernel.org/r/20211020174406.17889-18-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2021-10-29signal/x86: In emulate_vsyscall force a signal instead of calling do_exitEric W. Biederman
Directly calling do_exit with a signal number has the problem that all of the side effects of the signal don't happen, such as killing all of the threads of a process instead of just the calling thread. So replace do_exit(SIGSYS) with force_fatal_sig(SIGSYS) which causes the signal handling to take it's normal path and work as expected. Cc: Andy Lutomirski <luto@kernel.org> Link: https://lkml.kernel.org/r/20211020174406.17889-17-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2021-10-29signal/sparc32: In setup_rt_frame and setup_fram use force_fatal_sigEric W. Biederman
Modify the 32bit version of setup_rt_frame and setup_frame to act similar to the 64bit version of setup_rt_frame and fail with a signal instead of calling do_exit. Replacing do_exit(SIGILL) with force_fatal_signal(SIGILL) ensures that the process will be terminated cleanly when the stack frame is invalid, instead of just killing off a single thread and leaving the process is a weird state. Cc: David Miller <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Link: https://lkml.kernel.org/r/20211020174406.17889-16-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2021-10-29signal/sparc32: Exit with a fatal signal when try_to_clear_window_buffer failsEric W. Biederman
The function try_to_clear_window_buffer is only called from rtrap_32.c. After it is called the signal pending state is retested, and signals are handled if TIF_SIGPENDING is set. This allows try_to_clear_window_buffer to call force_fatal_signal and then rely on the signal being delivered to kill the process, without any danger of returning to userspace, or otherwise using possible corrupt state on failure. The functional difference between force_fatal_sig and do_exit is that do_exit will only terminate a single thread, and will never trigger a core-dump. A multi-threaded program for which a single thread terminates unexpectedly is hard to reason about. Calling force_fatal_sig does not give userspace a chance to catch the signal, but otherwise is an ordinary fatal signal exit, and it will trigger a coredump of the offending process if core dumps are enabled. Cc: David Miller <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Link: https://lkml.kernel.org/r/20211020174406.17889-15-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2021-10-29exit/syscall_user_dispatch: Send ordinary signals on failureEric W. Biederman
Use force_fatal_sig instead of calling do_exit directly. This ensures the ordinary signal handling path gets invoked, core dumps as appropriate get created, and for multi-threaded processes all of the threads are terminated not just a single thread. When asked Gabriel Krisman Bertazi <krisman@collabora.com> said [1]: > ebiederm@xmission.com (Eric W. Biederman) asked: > > > Why does do_syscal_user_dispatch call do_exit(SIGSEGV) and > > do_exit(SIGSYS) instead of force_sig(SIGSEGV) and force_sig(SIGSYS)? > > > > Looking at the code these cases are not expected to happen, so I would > > be surprised if userspace depends on any particular behaviour on the > > failure path so I think we can change this. > > Hi Eric, > > There is not really a good reason, and the use case that originated the > feature doesn't rely on it. > > Unless I'm missing yet another problem and others correct me, I think > it makes sense to change it as you described. > > > Is using do_exit in this way something you copied from seccomp? > > I'm not sure, its been a while, but I think it might be just that. The > first prototype of SUD was implemented as a seccomp mode. If at some point it becomes interesting we could relax "force_fatal_sig(SIGSEGV)" to instead say "force_sig_fault(SIGSEGV, SEGV_MAPERR, sd->selector)". I avoid doing that in this patch to avoid making it possible to catch currently uncatchable signals. Cc: Gabriel Krisman Bertazi <krisman@collabora.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> [1] https://lkml.kernel.org/r/87mtr6gdvi.fsf@collabora.com Link: https://lkml.kernel.org/r/20211020174406.17889-14-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2021-10-29signal: Implement force_fatal_sigEric W. Biederman
Add a simple helper force_fatal_sig that causes a signal to be delivered to a process as if the signal handler was set to SIG_DFL. Reimplement force_sigsegv based upon this new helper. This fixes force_sigsegv so that when it forces the default signal handler to be used the code now forces the signal to be unblocked as well. Reusing the tested logic in force_sig_info_to_task that was built for force_sig_seccomp this makes the implementation trivial. This is interesting both because it makes force_sigsegv simpler and because there are a couple of buggy places in the kernel that call do_exit(SIGILL) or do_exit(SIGSYS) because there is no straight forward way today for those places to simply force the exit of a process with the chosen signal. Creating force_fatal_sig allows those places to be implemented with normal signal exits. Link: https://lkml.kernel.org/r/20211020174406.17889-13-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2021-10-29exit/kthread: Have kernel threads return instead of calling do_exitEric W. Biederman
In 2009 Oleg reworked[1] the kernel threads so that it is not necessary to call do_exit if you are not using kthread_stop(). Remove the explicit calls of do_exit and complete_and_exit (with a NULL completion) that were previously necessary. [1] 63706172f332 ("kthreads: rework kthread_stop()") Link: https://lkml.kernel.org/r/20211020174406.17889-12-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2021-10-29signal/s390: Use force_sigsegv in default_trap_handlerEric W. Biederman
Reading the history it is unclear why default_trap_handler calls do_exit. It is not even menthioned in the commit where the change happened. My best guess is that because it is unknown why the exception happened it was desired to guarantee the process never returned to userspace. Using do_exit(SIGSEGV) has the problem that it will only terminate one thread of a process, leaving the process in an undefined state. Use force_sigsegv(SIGSEGV) instead which effectively has the same behavior except that is uses the ordinary signal mechanism and terminates all threads of a process and is generally well defined. Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: linux-s390@vger.kernel.org Fixes: ca2ab03237ec ("[PATCH] s390: core changes") History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Link: https://lkml.kernel.org/r/20211020174406.17889-11-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2021-10-29i2c: i801: Fix incorrect and needless software PEC disablingJarkko Nikula
Commit a6b8bb6a813a ("i2c: i801: Fix handling SMBHSTCNT_PEC_EN") attempts to disable software PEC by clearing the SMBHSTCNT_PEC_EN (bit 7) in the SMBus Host Control register (I/O SMBHSTCNT) but incorrectly clears it in the PCI Host Configuration register (PCI SMBHSTCFG). This clearing is actually needless since after above commit the SMBHSTCNT_PEC_EN is never set and the register is initialized with known values. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2021-10-29selftests/core: fix conflicting types compile error for close_range()Shuah Khan
close_range() test type conflicts with close_range() library call in x86_64-linux-gnu/bits/unistd_ext.h. Fix it by changing the name to core_close_range(). gcc -g -I../../../../usr/include/ close_range_test.c -o ../tools/testing/selftests/core/close_range_test In file included from close_range_test.c:16: close_range_test.c:57:6: error: conflicting types for ‘close_range’; have ‘void(struct __test_metadata *)’ 57 | TEST(close_range) | ^~~~~~~~~~~ ../kselftest_harness.h:181:21: note: in definition of macro ‘__TEST_IMPL’ 181 | static void test_name(struct __test_metadata *_metadata); \ | ^~~~~~~~~ close_range_test.c:57:1: note: in expansion of macro ‘TEST’ 57 | TEST(close_range) | ^~~~ In file included from /usr/include/unistd.h:1204, from close_range_test.c:13: /usr/include/x86_64-linux-gnu/bits/unistd_ext.h:56:12: note: previous declaration of ‘close_range’ with type ‘int(unsigned int, unsigned int, int)’ 56 | extern int close_range (unsigned int __fd, unsigned int __max_fd, | ^~~~~~~~~~~ Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-10-29kunit: tool: fix typecheck errors about loading qemu configsDaniel Latypov
Currently, we have these errors: $ mypy ./tools/testing/kunit/*.py tools/testing/kunit/kunit_kernel.py:213: error: Item "_Loader" of "Optional[_Loader]" has no attribute "exec_module" tools/testing/kunit/kunit_kernel.py:213: error: Item "None" of "Optional[_Loader]" has no attribute "exec_module" tools/testing/kunit/kunit_kernel.py:214: error: Module has no attribute "QEMU_ARCH" tools/testing/kunit/kunit_kernel.py:215: error: Module has no attribute "QEMU_ARCH" exec_module =========== pytype currently reports no errors, but that's because there's a comment disabling it on 213. This is due to https://github.com/python/typeshed/pull/2626. The fix is to assert the loaded module implements the ABC (abstract base class) we want which has exec_module support. QEMU_ARCH ========= pytype is fine with this, but mypy is not: https://github.com/python/mypy/issues/5059 Add a check that the loaded module does indeed have QEMU_ARCH. Note: this is not enough to appease mypy, so we also add a comment to squash the warning. Signed-off-by: Daniel Latypov <dlatypov@google.com> Reviewed-by: David Gow <davidgow@google.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-10-29ocxl: Use pci core's DVSEC functionalityBen Widawsky
Reduce maintenance burden of DVSEC query implementation by using the centralized PCI core implementation. There are two obvious places to simply drop in the new core implementation. There remains find_dvsec_from_pos() which would benefit from using a core implementation. As that change is less trivial it is reserved for later. Cc: linuxppc-dev@lists.ozlabs.org Cc: Andrew Donnellan <ajd@linux.ibm.com> Acked-by: Frederic Barrat <fbarrat@linux.ibm.com> (v1) Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com> Link: https://lore.kernel.org/r/163379789065.692348.7117946955275586530.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-10-29cxl/pci: Use pci core's DVSEC functionalityBen Widawsky
Reduce maintenance burden of DVSEC query implementation by using the centralized PCI core implementation. Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> [djbw: kill cxl_pci_dvsec()] Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/163379788528.692348.11581080806976608802.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-10-29PCI: Add pci_find_dvsec_capability to find designated VSECBen Widawsky
Add pci_find_dvsec_capability to locate a Designated Vendor-Specific Extended Capability with the specified Vendor ID and Capability ID. The Designated Vendor-Specific Extended Capability (DVSEC) allows one or more "vendor" specific capabilities that are not tied to the Vendor ID of the PCI component. Where the DVSEC Vendor may be a standards body like CXL. Cc: David E. Box <david.e.box@linux.intel.com> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: linux-pci@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: Andrew Donnellan <ajd@linux.ibm.com> Cc: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/163379787943.692348.6814373487017444007.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-10-29cxl/pci: Split cxl_pci_setup_regs()Ben Widawsky
In preparation for moving parts of register mapping to cxl_core, split cxl_pci_setup_regs() into a helper that finds register blocks, (cxl_find_regblock()), and a generic wrapper that probes the precise register sets within a block (cxl_setup_regs()). Move the actual mapping (cxl_map_regs()) of the only register-set that cxl_pci cares about (memory device registers) up a level from the former cxl_pci_setup_regs() into cxl_pci_probe(). With this change the unused component registers are no longer mapped, but the helpers are primed to move into the core. [djbw: drop cxl_map_regs() for component registers] Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> [djbw: rebase on the cxl_register_map refactor] Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/163434053788.914258.18412599112859205220.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-10-29cxl/pci: Add @base to cxl_register_mapDan Williams
In addition to carrying @barno, @block_offset, and @reg_type, add @base to keep all map/unmap parameters in one object. The helpers cxl_{map,unmap}_regblock() handle adjusting @base to the @block_offset at map and unmap time. Document that @base incorporates @block_offset so that downstream consumers of a mapped cxl_register_map instance do not need perform any fixups / can use @base directly. Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/163433497228.889435.11271988238496181536.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-10-29cxl/pci: Make more use of cxl_register_mapBen Widawsky
The structure exists to pass around information about register mapping. Use it for passing @barno and @block_offset, and eliminate duplicate local variables. The helpers that use @map do not care about @cxlm, so just pass them a pdev instead. [djbw: reorder before cxl_pci_setup_regs() refactor to improver readability] Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> [djbw: separate @base conversion] Link: https://lore.kernel.org/r/163416901172.806743.10056306321247850914.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-10-29cxl/pci: Remove pci request/release regionsBen Widawsky
Quoting Dan, "... the request + release regions should probably just be dropped. It's not like any of the register enumeration would collide with someone else who already has the registers mapped. The collision only comes when the registers are mapped for their final usage, and that will have more precision in the request." Suggested-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Link: https://lore.kernel.org/r/163379785872.692348.8981679111988251260.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-10-29cxl/pci: Fix NULL vs ERR_PTR confusionDan Williams
cxl_pci_map_regblock() may return an ERR_PTR(), but cxl_pci_setup_regs() is only prepared for NULL as the error case. Pick the minimal fix for -stable backport purposes and just have cxl_pci_map_regblock() return NULL for errors. Fixes: f8a7e8c29be8 ("cxl/pci: Reserve all device regions at once") Cc: <stable@vger.kernel.org> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/163433325724.834522.17809774578178224149.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-10-29cxl/pci: Remove dev_dbg for unknown register blocksBen Widawsky
While interesting to driver developers, the dev_dbg message doesn't do much except clutter up logs. This information should be attainable through sysfs, and someday lspci like utilities. This change additionally helps reduce the LOC in a subsequent patch to refactor some of cxl_pci register mapping. Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> Link: https://lore.kernel.org/r/163379784717.692348.3478221381958300790.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-10-29cxl/pci: Convert register block identifiers to an enumBen Widawsky
In preparation for passing around the Register Block Indicator (RBI) as a parameter, it is desirable to convert the type to an enum so that the interface can use a well defined parameter. Signed-off-by: Ben Widawsky <ben.widawsky@intel.com> [djbw: changelog fixups ] Link: https://lore.kernel.org/r/163379784199.692348.4366131432595112771.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-10-29ice: Hide bus-info in ethtool for PRs in switchdev modeMarcin Szycik
Disable showing bus-info information for port representors in switchdev mode. This fixes a bug that caused displaying wrong netdev descriptions in lshw tool - one port representor displayed PF branding string, and in turn one PF displayed a "generic" description. The bug occurs when many devices show the same bus-info in ethtool, which was the case in switchdev mode (PF and its port representors displayed the same bus-info). The bug occurs only if a port representor netdev appears before PF netdev in /proc/net/dev. In the examples below: ens6fX is PF ens6fXvY is VF ethX is port representor One irrelevant column was removed from output Before: $ sudo lshw -c net -businfo Bus info Device Description ========================================= pci@0000:02:00.0 eth102 Ethernet Controller E810-XXV for SFP pci@0000:02:00.1 ens6f1 Ethernet Controller E810-XXV for SFP pci@0000:02:01.0 ens6f0v0 Ethernet Adaptive Virtual Function pci@0000:02:01.1 ens6f0v1 Ethernet Adaptive Virtual Function pci@0000:02:01.2 ens6f0v2 Ethernet Adaptive Virtual Function pci@0000:02:00.0 ens6f0 Ethernet interface Notice that eth102 and ens6f0 have the same bus-info and their descriptions are swapped. After: $ sudo lshw -c net -businfo Bus info Device Description ========================================= pci@0000:02:00.0 ens6f0 Ethernet Controller E810-XXV for SFP pci@0000:02:00.1 ens6f1 Ethernet Controller E810-XXV for SFP pci@0000:02:01.0 ens6f0v0 Ethernet Adaptive Virtual Function pci@0000:02:01.1 ens6f0v1 Ethernet Adaptive Virtual Function pci@0000:02:01.2 ens6f0v2 Ethernet Adaptive Virtual Function Fixes: 7aae80cef7ba ("ice: add port representor ethtool ops and stats") Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-10-29Merge tag 'block-5.15-2021-10-29' of git://git.kernel.dk/linux-blockLinus Torvalds
Pull block fixes from Jens Axboe: - NVMe pull request: - fix nvmet-tcp header digest verification (Amit Engel) - fix a memory leak in nvmet-tcp when releasing a queue (Maurizio Lombardi) - fix nvme-tcp H2CData PDU send accounting again (Sagi Grimberg) - fix digest pointer calculation in nvme-tcp and nvmet-tcp (Varun Prakash) - fix possible nvme-tcp req->offset corruption (Varun Prakash) - Queue drain ordering fix (Ming) - Partition check regression for zoned devices (Shin'ichiro) - Zone queue restart fix (Naohiro) * tag 'block-5.15-2021-10-29' of git://git.kernel.dk/linux-block: block: Fix partition check for host-aware zoned block devices nvmet-tcp: fix header digest verification nvmet-tcp: fix data digest pointer calculation nvme-tcp: fix data digest pointer calculation nvme-tcp: fix possible req->offset corruption block: schedule queue restart after BLK_STS_ZONE_RESOURCE block: drain queue after disk is removed from sysfs nvme-tcp: fix H2CData PDU send accounting (again) nvmet-tcp: fix a memory leak when releasing a queue
2021-10-29scsi: mpt3sas: Fix reference tag handling for WRITE_INSERTMartin K. Petersen
Testing revealed a problem with how the reference tag was handled for a WRITE_INSERT operation. The SCSI_PROT_REF_CHECK flag is not set when the controller is asked to generate the protection information (i.e. not DIX). And as a result the initial reference tag would not be set in the WRITE_INSERT case. Separate handling of the REF_CHECK and REF_INCREMENT flags to align with both the DIX spec and the MPI implementation. Link: https://lore.kernel.org/r/20211028034202.24225-1-martin.petersen@oracle.com Fixes: b3e2c72af1d5 ("scsi: mpt3sas: Use the proper SCSI midlayer interfaces for PI") Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-10-29ice: Clear synchronized addrs when adding VFs in switchdev modeMarcin Szycik
When spawning VFs in switchdev mode, internal filter list of VSIs is cleared, which includes MAC rules. However MAC entries stay on netdev's multicast list, which causes error message when bringing link up after spawning VFs ("Failed to delete MAC filters"). __dev_mc_sync() is called and tries to unsync addresses that were already removed internally when adding VFs. This can be reproduced with: 1) Load ice driver 2) Change PF to switchdev mode 3) Bring PF link up 4) Bring PF link down 5) Create a VF on PF 6) Bring PF link up Added clearing of netdev's multicast (and also unicast) list when spawning VFs in switchdev mode, so the state of internal rule list and netdev's MAC list is consistent. Fixes: 1a1c40df2e80 ("ice: set and release switchdev environment") Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-10-29spi: Convert NXP flexspi to json schemaKuldeep Singh
Convert the NXP FlexSPI binding to DT schema format using json-schema. Signed-off-by: Kuldeep Singh <kuldeep.singh@nxp.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210927105818.445675-1-kuldeep.singh@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-10-29ASoC: rsnd: Fix an error handling path in 'rsnd_node_count()'Christophe JAILLET
If we return before the end of the 'for_each_child_of_node()' iterator, the reference taken on 'np' must be released. Add the missing 'of_node_put()' call. Fixes: c413983eb66a ("ASoC: rsnd: adjust disabled module") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/4c0e893cbfa21dc76c1ede0b6f4f8cff42209299.1634586167.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2021-10-29ASoC: tlv320aic3x: Make aic3x_remove() return voidUwe Kleine-König
Up to now aic3x_remove() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and spi remove callbacks is ignored anyway. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20211019074125.3812513-1-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2021-10-29ASoC: Intel: soc-acpi: use const for all uses of snd_soc_acpi_codecsPierre-Louis Bossart
'const' qualifiers are missing on some platforms, add as needed. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Brent Lu <brent.lu@intel.com> Link: https://lore.kernel.org/r/20211029171409.611600-7-brent.lu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-10-29ASoC: Intel: soc-acpi-cht: shrink tables using compatible IDsPierre-Louis Bossart
We have multiple entries for the same codecs, use the new compatible IDs to have a single entry. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Brent Lu <brent.lu@intel.com> Link: https://lore.kernel.org/r/20211029171409.611600-6-brent.lu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-10-29ASoC: Intel: soc-acpi-byt: shrink tables using compatible IDsPierre-Louis Bossart
We have multiple entries for the same codecs, use the new compatible IDs to have a single entry. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Brent Lu <brent.lu@intel.com> Link: https://lore.kernel.org/r/20211029171409.611600-5-brent.lu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-10-29ASoC: Intel: sof_rt5682: use comp_ids to enumerate rt5682sBrent Lu
Use comp_ids field to enumerate rt5682/rt5682s headphone codec for JSL/TGL/ADL devices and remove redundant entries in tables. Signed-off-by: Brent Lu <brent.lu@intel.com> Link: https://lore.kernel.org/r/20211029171409.611600-4-brent.lu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-10-29ASoC: Intel: sof_rt5682: detect codec variant in probe functionBrent Lu
Detect whether the headphone codec is ALC5682I-VS or not in probe function so we don't need to duplicate all board configs for this new variant. Signed-off-by: Brent Lu <brent.lu@intel.com> Link: https://lore.kernel.org/r/20211029171409.611600-3-brent.lu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-10-29ASoC: soc-acpi: add comp_ids field for machine driver matchingBrent Lu
A machine driver needs to be enumerated by more than one ACPI HID if it supports second headphone driver (i.e. rt5682 and rt5682s). However, the id field in snd_soc_acpi_mach structure could contain only one HID. By adding a 'comp_ids' field which can contain several HIDs, we can enumerate a machine driver by multiple ACPI HIDs. Signed-off-by: Brent Lu <brent.lu@intel.com> Link: https://lore.kernel.org/r/20211029171409.611600-2-brent.lu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-10-29Merge tag 'mmc-v5.15-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC fixes from Ulf Hansson: - tmio: Re-enable card irqs after a reset - mtk-sd: Fixup probing of cqhci for crypto - cqhci: Fix support for suspend/resume - vub300: Fix control-message timeouts - dw_mmc-exynos: Fix support for tuning - winbond: Silences build errors on M68K - sdhci-esdhc-imx: Fix support for tuning - sdhci-pci: Read card detect from ACPI for Intel Merrifield - sdhci: Fix eMMC support for Thundercomm TurboX CM2290 * tag 'mmc-v5.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: tmio: reenable card irqs after the reset callback mmc: mediatek: Move cqhci init behind ungate clock mmc: cqhci: clear HALT state after CQE enable mmc: vub300: fix control-message timeouts mmc: dw_mmc: exynos: fix the finding clock sample value mmc: winbond: don't build on M68K mmc: sdhci-esdhc-imx: clear the buffer_read_ready to reset standard tuning circuit mmc: sdhci-pci: Read card detect from ACPI for Intel Merrifield mmc: sdhci: Map more voltage level to SDHCI_POWER_330
2021-10-29ice: Remove boolean vlan_promisc flag from functionBrett Creeley
Currently, the vlan_promisc flag is used exclusively by VF VSI to determine whether or not to toggle VLAN pruning along with trusted/true-promiscuous mode. This is not needed for a couple of reasons. First, trusted/true-promiscuous mode is only supposed to allow all MAC filters within VLANs that a VF has added filters for, so VLAN pruning should not be disabled. Second, the boolean argument makes the function confusing and unintuitive. Remove this flag. Signed-off-by: Brett Creeley <brett.creeley@intel.com> Tested-by: Tony Brelinski <tony.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-10-29Merge tag 'for-5.15-rc7-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: "Last minute fixes for crash on 32bit architectures when compression is in use. It's a regression introduced in 5.15-rc and I'd really like not let this into the final release, fixes via stable trees would add unnecessary delay. The problem is on 32bit architectures with highmem enabled, the pages for compression may need to be kmapped, while the patches removed that as we don't use GFP_HIGHMEM allocations anymore. The pages that don't come from local allocation still may be from highmem. Despite being on 32bit there's enough such ARM machines in use so it's not a marginal issue. I did full reverts of the patches one by one instead of a huge one. There's one exception for the "lzo" revert as there was an intermediate patch touching the same code to make it compatible with subpage. I can't revert that one too, so the revert in lzo.c is manual. Qu Wenruo has worked on that with me and verified the changes" * tag 'for-5.15-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: Revert "btrfs: compression: drop kmap/kunmap from lzo" Revert "btrfs: compression: drop kmap/kunmap from zlib" Revert "btrfs: compression: drop kmap/kunmap from zstd" Revert "btrfs: compression: drop kmap/kunmap from generic helpers"
generated by cgit (git 2.34.1) at 2025-09-18 05:58:03 +0000