aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2021-09-15HID: amd_sfh: switch from 'pci_' to 'dma_' APIChristophe JAILLET1-2/+2
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below. It has been compile tested. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-09-02d_path: make 'prepend()' fill up the buffer exactly on overflowLinus Torvalds1-30/+63
Instead of just marking the buffer as having overflowed, fill it up as much as we can. That will allow the overflow case to then return whatever truncated result if it wants to. Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-02mm: don't allow oversized kvmalloc() callsLinus Torvalds1-0/+4
'kvmalloc()' is a convenience function for people who want to do a kmalloc() but fall back on vmalloc() if there aren't enough physically contiguous pages, or if the allocation is larger than what kmalloc() supports. However, let's make sure it doesn't get _too_ easy to do crazy things with it. In particular, don't allow big allocations that could be due to integer overflow or underflow. So make sure the allocation size fits in an 'int', to protect against trivial integer conversion issues. Acked-by: Willy Tarreau <w@1wt.eu> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-02iwlwifi: mvm: add rtnl_lock() in iwl_mvm_start_get_nvm()Luca Coelho1-0/+1
Due to a rebase damage, we lost the rtnl_lock() when the patch was sent out. This causes an RTNL imbalance and failed assertions, due to missing RTNL protection, for instance: RTNL: assertion failed at net/wireless/reg.c (4025) WARNING: CPU: 60 PID: 1720 at net/wireless/reg.c:4025 regulatory_set_wiphy_regd_sync+0x7f/0x90 [cfg80211] Call Trace: iwl_mvm_init_mcc+0x170/0x190 [iwlmvm] iwl_op_mode_mvm_start+0x824/0xa60 [iwlmvm] iwl_opmode_register+0xd0/0x130 [iwlwifi] init_module+0x23/0x1000 [iwlmvm] Fix this by adding the missing rtnl_lock() back to the code. Fixes: eb09ae93dabf ("iwlwifi: mvm: load regdomain at INIT stage") Link: https://lore.kernel.org/lkml/CAHk-=wjB_zBwZ+WR9LOpvgjvaQn=cqryoKigod8QnZs=iYGEhA@mail.gmail.com/ Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-01parisc: math-emu: Fix fall-through warningsHelge Deller1-3/+53
Fix lots of fallthrough warnings, e.g.: arch/parisc/math-emu/fpudispatch.c:323:33: warning: this statement may fall through [-Wimplicit-fallthrough=] Signed-off-by: Helge Deller <deller@gmx.de>
2021-09-01parisc: fix crash with signals and allocaMikulas Patocka1-0/+6
I was debugging some crashes on parisc and I found out that there is a crash possibility if a function using alloca is interrupted by a signal. The reason for the crash is that the gcc alloca implementation leaves garbage in the upper 32 bits of the sp register. This normally doesn't matter (the upper bits are ignored because the PSW W-bit is clear), however the signal delivery routine in the kernel uses full 64 bits of sp and it fails with -EFAULT if the upper 32 bits are not zero. I created this program that demonstrates the problem: #include <stdlib.h> #include <unistd.h> #include <signal.h> #include <alloca.h> static __attribute__((noinline,noclone)) void aa(int *size) { void * volatile p = alloca(-*size); while (1) ; } static void handler(int sig) { write(1, "signal delivered\n", 17); _exit(0); } int main(void) { int size = -0x100; signal(SIGALRM, handler); alarm(1); aa(&size); } If you compile it with optimizations, it will crash. The "aa" function has this disassembly: 000106a0 <aa>: 106a0: 08 03 02 41 copy r3,r1 106a4: 08 1e 02 43 copy sp,r3 106a8: 6f c1 00 80 stw,ma r1,40(sp) 106ac: 37 dc 3f c1 ldo -20(sp),ret0 106b0: 0c 7c 12 90 stw ret0,8(r3) 106b4: 0f 40 10 9c ldw 0(r26),ret0 ; ret0 = 0x00000000FFFFFF00 106b8: 97 9c 00 7e subi 3f,ret0,ret0 ; ret0 = 0xFFFFFFFF0000013F 106bc: d7 80 1c 1a depwi 0,31,6,ret0 ; ret0 = 0xFFFFFFFF00000100 106c0: 0b 9e 0a 1e add,l sp,ret0,sp ; sp = 0xFFFFFFFFxxxxxxxx 106c4: e8 1f 1f f7 b,l,n 106c4 <aa+0x24>,r0 This patch fixes the bug by truncating the "usp" variable to 32 bits. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Helge Deller <deller@gmx.de>
2021-09-01parisc: Fix compile failure when building 64-bit kernel nativelyMasahiro Yamada3-4/+9
Commit 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") broke 64-bit parisc builds on 32-bit parisc systems. Helge mentioned: - 64-bit parisc userspace is not supported yet [1] - hppa gcc does not support "-m64" flag [2] That means, parisc developers working on a 32-bit parisc machine need to use hppa64-linux-gnu-gcc (cross compiler) for building the 64-bit parisc kernel. After the offending commit, gcc is used in such a case because both $(SRCARCH) and $(SUBARCH) are 'parisc', hence cross_compiling is unset. A correct way is to introduce ARCH=parisc64 because building the 64-bit parisc kernel on a 32-bit parisc system is not exactly a native build, but rather a semi-cross build. [1]: https://lore.kernel.org/linux-parisc/5dfd81eb-c8ca-b7f5-e80e-8632767c022d@gmx.de/#t [2]: https://lore.kernel.org/linux-parisc/89515325-fc21-31da-d238-6f7a9abbf9a0@gmx.de/ Fixes: 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reported-by: Meelis Roos <mroos@linux.ee> Tested-by: Meelis Roos <mroos@linux.ee> Cc: <stable@vger.kernel.org> # v5.13+ Signed-off-by: Helge Deller <deller@gmx.de>
2021-09-01parisc: ccio-dma.c: Added tab instead of spacesShubhankar Kuranagatti1-43/+43
Single spaces has been removed and replaced with tabs. This is done to maintain code uniformity. Signed-off-by: Shubhankar Kuranagatti <shubhankarvk@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Helge Deller <deller@gmx.de>
2021-09-01HID: usbhid: Simplify code in hid_submit_ctrl()Alan Stern1-8/+4
This patch makes a small simplification to the code in hid_submit_ctrl(). The test for maxpacket being > 0 is unnecessary, because endpoint 0 always has a maxpacket value which is >= 8. Furthermore, endpoint 0's maxpacket value is always a power of 2, so instead of open-coding the round-to-next-multiple computation we can call the optimized round_up() routine. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-09-01HID: usbhid: Fix warning caused by 0-length input reportsAlan Stern1-0/+1
Syzbot found a warning caused by hid_submit_ctrl() submitting a control request to transfer a 0-length input report: usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType a1 (The warning message is a little difficult to understand. It means that the control request claims to be for an IN transfer but this contradicts the USB spec, which requires 0-length control transfers always to be in the OUT direction.) Now, a zero-length report isn't good for anything and there's no reason for a device to have one, but the fuzzer likes to pick out these weird edge cases. In the future, perhaps we will decide to reject 0-length reports at probe time. For now, the simplest approach for avoiding these warnings is to pretend that the report actually has length 1. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: syzbot+9b57a46bf1801ce2a2ca@syzkaller.appspotmail.com Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-09-01HID: usbhid: Fix flood of "control queue full" messagesMichal Kubecek1-8/+7
[patch description by Alan Stern] Commit 7652dd2c5cb7 ("USB: core: Check buffer length matches wLength for control transfers") causes control URB submissions to fail if the transfer_buffer_length value disagrees with the setup packet's wLength valuel. Unfortunately, it turns out that the usbhid can trigger this failure mode when it submits a control request for an input report: It pads the transfer buffer size to a multiple of the maxpacket value but does not increase wLength correspondingly. These failures have caused problems for people using an APS UPC, in the form of a flood of log messages resembling: hid-generic 0003:051D:0002.0002: control queue full This patch fixes the problem by setting the wLength value equal to the padded transfer_buffer_length value in hid_submit_ctrl(). As a nice bonus, the code which stores the transfer_buffer_length value is now shared between the two branches of an "if" statement, so it can be de-duplicated. Signed-off-by: Michal Kubecek <mkubecek@suse.cz> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Fixes: 7652dd2c5cb7 ("USB: core: Check buffer length matches wLength for control transfers") Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-09-01x86/setup: Explicitly include acpi.hNathan Chancellor1-0/+1
After commit 342f43af70db ("iscsi_ibft: fix crash due to KASLR physical memory remapping") x86_64_defconfig shows the following errors: arch/x86/kernel/setup.c: In function ‘setup_arch’: arch/x86/kernel/setup.c:916:13: error: implicit declaration of function ‘acpi_mps_check’ [-Werror=implicit-function-declaration] 916 | if (acpi_mps_check()) { | ^~~~~~~~~~~~~~ arch/x86/kernel/setup.c:1110:9: error: implicit declaration of function ‘acpi_table_upgrade’ [-Werror=implicit-function-declaration] 1110 | acpi_table_upgrade(); | ^~~~~~~~~~~~~~~~~~ [... more acpi noise ...] acpi.h was being implicitly included from iscsi_ibft.h in this configuration so the removal of that header means these functions have no definition or declaration. In most other configurations, <linux/acpi.h> continued to be included through at least <linux/tboot.h> if CONFIG_INTEL_TXT was enabled, and there were probably other implicit include paths too. Add acpi.h explicitly so there is no more error, and so that we don't continue to depend on these unreliable implicit include paths. Tested-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Cc: Maurizio Lombardi <mlombard@redhat.com> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Konrad Rzeszutek Wilk <konrad@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-09-01fs: dlm: avoid comms shutdown delay in release_lockspaceAlexander Aring1-0/+1
When dlm_release_lockspace does active shutdown on connections to other nodes, the active shutdown will wait for any exisitng passive shutdowns to be resolved. But, the sequence of operations during dlm_release_lockspace can prevent the normal resolution of passive shutdowns (processed normally by way of lockspace recovery.) This disruption of passive shutdown handling can cause the active shutdown to wait for a full timeout period, delaying the completion of dlm_release_lockspace. To fix this, make dlm_release_lockspace resolve existing passive shutdowns (by calling dlm_clear_members earlier), before it does active shutdowns. The active shutdowns will not find any passive shutdowns to wait for, and will not be delayed. Reported-by: Chris Mackowski <cmackows@redhat.com> Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
2021-09-01xen: remove stray preempt_disable() from PV AP startup codeJuergen Gross1-1/+0
In cpu_bringup() there is a call of preempt_disable() without a paired preempt_enable(). This is not needed as interrupts are off initially. Additionally this will result in early boot messages like: BUG: scheduling while atomic: swapper/1/0/0x00000002 Signed-off-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20210825113158.11716-1-jgross@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-09-01xen/pcifront: Removed unnecessary __ref annotationSergio Miguéns Iglesias1-11/+19
An unnecessary "__ref" annotation was removed from the "drivers/pci/xen_pcifront.c" file. The function where the annotation was used was "pcifront_backend_changed()", which does not call any functions annotated as "__*init" nor "__*exit". This makes "__ref" unnecessary since this annotation is used to make the compiler ignore section miss-matches when they are not happening here in the first place. In addition to the aforementioned change, some code style issues were fixed in the same file. Signed-off-by: Sergio Miguéns Iglesias <sergio@lony.xyz> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20210830175305.13370-1-sergio@lony.xyz Signed-off-by: Juergen Gross <jgross@suse.com>
2021-08-31dt-bindings: clock: samsung: fix header path in exampleKrzysztof Kozlowski1-1/+1
The proper header is exynos4.h: samsung,exynos4412-isp-clock.example.dts:19:18: fatal error: dt-bindings/clock/exynos4412.h: No such file or directory Fixes: 7ac615780926 ("dt-bindings: clock: samsung: convert Exynos4 to dtschema") Reported-by: Stephen Boyd <sboyd@kernel.org> Reported-by: Rob Herring <robh+dt@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210831130643.83249-1-krzysztof.kozlowski@canonical.com Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2021-08-31mailbox: cmdq: add multi-gce clocks support for mt8195jason-jh.lin1-22/+79
For the design of GCE hardware event signal transportation, evnet rx will send the event signal to all GCE event merges after receiving the event signal from the other hardware. Because GCE event merges need to response to event rx, their clocks must be enabled at that time. To make sure all the gce clock is enabled while receiving the hardware event, each cmdq mailbox should enable or disable the others gce clk at the same time. Signed-off-by: jason-jh.lin <jason-jh.lin@mediatek.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
2021-08-31mailbox: cmdq: add mediatek mailbox support for mt8195jason-jh.lin1-0/+1
Add mt8195 compatible name in the driver data of cmdq mailbox driver. Signed-off-by: jason-jh.lin <jason-jh.lin@mediatek.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>