summaryrefslogtreecommitdiffstats
path: root/Makefile (unfollow)
Commit message (Collapse)AuthorFilesLines
2020-12-03hwmon: (pmbus/max20730) delete some dead codeDan Carpenter1-2/+0
The debugfs_create_dir() function never returns NULL. Normal users are not supposed to check the return value so the correct fix is just to delete this check. In the case where the debugfs_create_dir() fails, the function returns NULL. The other debugfs function check for NULL directory and handle it. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20201022070659.GA2817762@mwanda Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-12-03hwmon: (acpi_power_meter) clean up freeing codeDan Carpenter1-5/+4
This code works okay but Smatch flagged it as a double free. I've changed three things to make it more clear. 1) Remove the call to free_capabilities() in acpi_power_meter_add(). This call is a no-op because the capabilities have not been allocated yet. 2) Set "*str" to NULL in free_capabilities() so that way the function can be called twice in a row without leading to a double free. 3) Call free_capabilities() in read_capabilities() instead of open coding the free. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20201007075148.GB2529578@mwanda Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-12-03hwmon: (ina3221) Fix PM usage counter unbalance in ina3221_write_enableZhang Qilong1-1/+1
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. It depends on the mainline commit[PM: runtime: Add pm_runtime_resume_and_get to deal with usagecounter]. Fixes: 323aeb0eb5d9a ("hwmon: (ina3221) Add PM runtime support") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201202145320.1135614-1-zhangqilong3@huawei.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2020-11-30Linux 5.10-rc6v5.10-rc6Linus Torvalds1-1/+1
2020-11-27sock: set sk_err to ee_errno on dequeue from errqWillem de Bruijn1-1/+1
When setting sk_err, set it to ee_errno, not ee_origin. Commit f5f99309fa74 ("sock: do not set sk_err in sock_dequeue_err_skb") disabled updating sk_err on errq dequeue, which is correct for most error types (origins): - sk->sk_err = err; Commit 38b257938ac6 ("sock: reset sk_err when the error queue is empty") reenabled the behavior for IMCP origins, which do require it: + if (icmp_next) + sk->sk_err = SKB_EXT_ERR(skb_next)->ee.ee_origin; But read from ee_errno. Fixes: 38b257938ac6 ("sock: reset sk_err when the error queue is empty") Reported-by: Ayush Ranjan <ayushranjan@google.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Link: https://lore.kernel.org/r/20201126151220.2819322-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-27mptcp: fix NULL ptr dereference on bad MPJPaolo Abeni1-3/+2
If an msk listener receives an MPJ carrying an invalid token, it will zero the request socket msk entry. That should later cause fallback and subflow reset - as per RFC - at subflow_syn_recv_sock() time due to failing hmac validation. Since commit 4cf8b7e48a09 ("subflow: introduce and use mptcp_can_accept_new_subflow()"), we unconditionally dereference - in mptcp_can_accept_new_subflow - the subflow request msk before performing hmac validation. In the above scenario we hit a NULL ptr dereference. Address the issue doing the hmac validation earlier. Fixes: 4cf8b7e48a09 ("subflow: introduce and use mptcp_can_accept_new_subflow()") Tested-by: Davide Caratti <dcaratti@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Link: https://lore.kernel.org/r/03b2cfa3ac80d8fc18272edc6442a9ddf0b1e34e.1606400227.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-27net: openvswitch: fix TTL decrement action netlink message formatEelco Chaudron3-23/+60
Currently, the openvswitch module is not accepting the correctly formated netlink message for the TTL decrement action. For both setting and getting the dec_ttl action, the actions should be nested in the OVS_DEC_TTL_ATTR_ACTION attribute as mentioned in the openvswitch.h uapi. When the original patch was sent, it was tested with a private OVS userspace implementation. This implementation was unfortunately not upstreamed and reviewed, hence an erroneous version of this patch was sent out. Leaving the patch as-is would cause problems as the kernel module could interpret additional attributes as actions and vice-versa, due to the actions not being encapsulated/nested within the actual attribute, but being concatinated after it. Fixes: 744676e77720 ("openvswitch: add TTL decrement action") Signed-off-by: Eelco Chaudron <echaudro@redhat.com> Link: https://lore.kernel.org/r/160622121495.27296.888010441924340582.stgit@wsfd-netdev64.ntdv.lab.eng.bos.redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-27perf probe: Change function definition check due to broken DWARFMasami Hiramatsu2-4/+19
Since some gcc generates a broken DWARF which lacks DW_AT_declaration attribute from the subprogram DIE of function prototype. (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060) So, in addition to the DW_AT_declaration check, we also check the subprogram DIE has DW_AT_inline or actual entry pc. Committer testing: # cat /etc/fedora-release Fedora release 33 (Thirty Three) # Before: # perf test vfs_getname 78: Use vfs_getname probe to get syscall args filenames : FAILED! 79: Check open filename arg using perf trace + vfs_getname : FAILED! 81: Add vfs_getname probe to get syscall args filenames : FAILED! # After: # perf test vfs_getname 78: Use vfs_getname probe to get syscall args filenames : Ok 79: Check open filename arg using perf trace + vfs_getname : Ok 81: Add vfs_getname probe to get syscall args filenames : Ok # Reported-by: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Sumanth Korikkar <sumanthk@linux.ibm.com> Link: http://lore.kernel.org/lkml/160645613571.2824037.7441351537890235895.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-11-27perf probe: Fix to die_entrypc() returns error correctlyMasami Hiramatsu1-0/+8
Fix die_entrypc() to return error correctly if the DIE has no DW_AT_ranges attribute. Since dwarf_ranges() will treat the case as an empty ranges and return 0, we have to check it by ourselves. Fixes: 91e2f539eeda ("perf probe: Fix to show function entry line as probe-able") Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Cc: Sumanth Korikkar <sumanthk@linux.ibm.com> Cc: Thomas Richter <tmricht@linux.ibm.com> Link: http://lore.kernel.org/lkml/160645612634.2824037.5284932731175079426.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-11-27perf stat: Use proper cpu for shadow statsNamhyung Kim1-4/+1
Currently perf stat shows some metrics (like IPC) for defined events. But when no aggregation mode is used (-A option), it shows incorrect values since it used a value from a different cpu. Before: $ perf stat -aA -e cycles,instructions sleep 1 Performance counter stats for 'system wide': CPU0 116,057,380 cycles CPU1 86,084,722 cycles CPU2 99,423,125 cycles CPU3 98,272,994 cycles CPU0 53,369,217 instructions # 0.46 insn per cycle CPU1 33,378,058 instructions # 0.29 insn per cycle CPU2 58,150,086 instructions # 0.50 insn per cycle CPU3 40,029,703 instructions # 0.34 insn per cycle 1.001816971 seconds time elapsed So the IPC for CPU1 should be 0.38 (= 33,378,058 / 86,084,722) but it was 0.29 (= 33,378,058 / 116,057,380) and so on. After: $ perf stat -aA -e cycles,instructions sleep 1 Performance counter stats for 'system wide': CPU0 109,621,384 cycles CPU1 159,026,454 cycles CPU2 99,460,366 cycles CPU3 124,144,142 cycles CPU0 44,396,706 instructions # 0.41 insn per cycle CPU1 120,195,425 instructions # 0.76 insn per cycle CPU2 44,763,978 instructions # 0.45 insn per cycle CPU3 69,049,079 instructions # 0.56 insn per cycle 1.001910444 seconds time elapsed Fixes: 44d49a600259 ("perf stat: Support metrics in --per-core/socket mode") Reported-by: Sam Xi <xyzsam@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Reviewed-by: Andi Kleen <ak@linux.intel.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lore.kernel.org/lkml/20201127041404.390276-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-11-27perf record: Synthesize cgroup events only if neededNamhyung Kim1-0/+3
It didn't check the tool->cgroup_events bit which is set when the --all-cgroups option is given. Without it, samples will not have cgroup info so no reason to synthesize. We can check the PERF_RECORD_CGROUP records after running perf record *WITHOUT* the --all-cgroups option: Before: $ perf report -D | grep CGROUP 0 0 0x8430 [0x38]: PERF_RECORD_CGROUP cgroup: 1 / CGROUP events: 1 CGROUP events: 0 CGROUP events: 0 After: $ perf report -D | grep CGROUP CGROUP events: 0 CGROUP events: 0 CGROUP events: 0 Committer testing: Before: # perf record -a sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 2.208 MB perf.data (10003 samples) ] # perf report -D | grep "CGROUP events" CGROUP events: 146 CGROUP events: 0 CGROUP events: 0 # After: # perf record -a sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 2.208 MB perf.data (10448 samples) ] # perf report -D | grep "CGROUP events" CGROUP events: 0 CGROUP events: 0 CGROUP events: 0 # With all-cgroups: # perf record --all-cgroups -a sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 2.374 MB perf.data (11526 samples) ] # perf report -D | grep "CGROUP events" CGROUP events: 146 CGROUP events: 0 CGROUP events: 0 # Fixes: 8fb4b67939e16 ("perf record: Add --all-cgroups option") Signed-off-by: Namhyung Kim <namhyung@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lore.kernel.org/lkml/20201127054356.405481-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-11-27perf diff: Fix error return value in __cmd_diff()Zhen Lei1-1/+3
An appropriate return value should be set on the failed path. Fixes: 2a09a84c720b436a ("perf diff: Support hot streams comparison") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20201124103652.438-1-thunder.leizhen@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-11-27perf tools: Update copy of libbpf's hashmap.cArnaldo Carvalho de Melo1-6/+9
To pick the changes in: 7a078d2d18801bba ("libbpf, hashmap: Fix undefined behavior in hash_bits") That don't entail any changes in tools/perf. This addresses this perf build warning: Warning: Kernel ABI header at 'tools/perf/util/hashmap.h' differs from latest version at 'tools/lib/bpf/hashmap.h' diff -u tools/perf/util/hashmap.h tools/lib/bpf/hashmap.h Not a kernel ABI, its just that this uses the mechanism in place for checking kernel ABI files drift. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2020-11-27x86/mce: Do not overwrite no_way_out if mce_end() failsGabriele Paoloni1-2/+4
Currently, if mce_end() fails, no_way_out - the variable denoting whether the machine can recover from this MCE - is determined by whether the worst severity that was found across the MCA banks associated with the current CPU, is of panic severity. However, at this point no_way_out could have been already set by mca_start() after looking at all severities of all CPUs that entered the MCE handler. If mce_end() fails, check first if no_way_out is already set and, if so, stick to it, otherwise use the local worst value. [ bp: Massage. ] Signed-off-by: Gabriele Paoloni <gabriele.paoloni@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Tony Luck <tony.luck@intel.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20201127161819.3106432-2-gabriele.paoloni@intel.com
2020-11-27kvm: x86/mmu: Fix get_mmio_spte() on CPUs supporting 5-level PTVitaly Kuznetsov1-1/+1
Commit 95fb5b0258b7 ("kvm: x86/mmu: Support MMIO in the TDP MMU") caused the following WARNING on an Intel Ice Lake CPU: get_mmio_spte: detect reserved bits on spte, addr 0xb80a0, dump hierarchy: ------ spte 0xb80a0 level 5. ------ spte 0xfcd210107 level 4. ------ spte 0x1004c40107 level 3. ------ spte 0x1004c41107 level 2. ------ spte 0x1db00000000b83b6 level 1. WARNING: CPU: 109 PID: 10254 at arch/x86/kvm/mmu/mmu.c:3569 kvm_mmu_page_fault.cold.150+0x54/0x22f [kvm] ... Call Trace: ? kvm_io_bus_get_first_dev+0x55/0x110 [kvm] vcpu_enter_guest+0xaa1/0x16a0 [kvm] ? vmx_get_cs_db_l_bits+0x17/0x30 [kvm_intel] ? skip_emulated_instruction+0xaa/0x150 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xca/0x520 [kvm] The guest triggering this crashes. Note, this happens with the traditional MMU and EPT enabled, not with the newly introduced TDP MMU. Turns out, there was a subtle change in the above mentioned commit. Previously, walk_shadow_page_get_mmio_spte() was setting 'root' to 'iterator.level' which is returned by shadow_walk_init() and this equals to 'vcpu->arch.mmu->shadow_root_level'. Now, get_mmio_spte() sets it to 'int root = vcpu->arch.mmu->root_level'. The difference between 'root_level' and 'shadow_root_level' on CPUs supporting 5-level page tables is that in some case we don't want to use 5-level, in particular when 'cpuid_maxphyaddr(vcpu) <= 48' kvm_mmu_get_tdp_level() returns '4'. In case upper layer is not used, the corresponding SPTE will fail '__is_rsvd_bits_set()' check. Revert to using 'shadow_root_level'. Fixes: 95fb5b0258b7 ("kvm: x86/mmu: Support MMIO in the TDP MMU") Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20201126110206.2118959-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-11-27KVM: x86: Fix split-irqchip vs interrupt injection window requestPaolo Bonzini3-9/+12
kvm_cpu_accept_dm_intr and kvm_vcpu_ready_for_interrupt_injection are a hodge-podge of conditions, hacked together to get something that more or less works. But what is actually needed is much simpler; in both cases the fundamental question is, do we have a place to stash an interrupt if userspace does KVM_INTERRUPT? In userspace irqchip mode, that is !vcpu->arch.interrupt.injected. Currently kvm_event_needs_reinjection(vcpu) covers it, but it is unnecessarily restrictive. In split irqchip mode it's a bit more complicated, we need to check kvm_apic_accept_pic_intr(vcpu) (the IRQ window exit is basically an INTACK cycle and thus requires ExtINTs not to be masked) as well as !pending_userspace_extint(vcpu). However, there is no need to check kvm_event_needs_reinjection(vcpu), since split irqchip keeps pending ExtINT state separate from event injection state, and checking kvm_cpu_has_interrupt(vcpu) is wrong too since ExtINT has higher priority than APIC interrupts. In fact the latter fixes a bug: when userspace requests an IRQ window vmexit, an interrupt in the local APIC can cause kvm_cpu_has_interrupt() to be true and thus kvm_vcpu_ready_for_interrupt_injection() to return false. When this happens, vcpu_run does not exit to userspace but the interrupt window vmexits keep occurring. The VM loops without any hope of making progress. Once we try to fix these with something like return kvm_arch_interrupt_allowed(vcpu) && - !kvm_cpu_has_interrupt(vcpu) && - !kvm_event_needs_reinjection(vcpu) && - kvm_cpu_accept_dm_intr(vcpu); + (!lapic_in_kernel(vcpu) + ? !vcpu->arch.interrupt.injected + : (kvm_apic_accept_pic_intr(vcpu) + && !pending_userspace_extint(v))); we realize two things. First, thanks to the previous patch the complex conditional can reuse !kvm_cpu_has_extint(vcpu). Second, the interrupt window request in vcpu_enter_guest() bool req_int_win = dm_request_for_irq_injection(vcpu) && kvm_cpu_accept_dm_intr(vcpu); should be kept in sync with kvm_vcpu_ready_for_interrupt_injection(): it is unnecessary to ask the processor for an interrupt window if we would not be able to return to userspace. Therefore, kvm_cpu_accept_dm_intr(vcpu) is basically !kvm_cpu_has_extint(vcpu) ANDed with the existing check for masked ExtINT. It all makes sense: - we can accept an interrupt from userspace if there is a place to stash it (and, for irqchip split, ExtINTs are not masked). Interrupts from userspace _can_ be accepted even if right now EFLAGS.IF=0. - in order to tell userspace we will inject its interrupt ("IRQ window open" i.e. kvm_vcpu_ready_for_interrupt_injection), both KVM and the vCPU need to be ready to accept the interrupt. ... and this is what the patch implements. Reported-by: David Woodhouse <dwmw@amazon.co.uk> Analyzed-by: David Woodhouse <dwmw@amazon.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Nikos Tsironis <ntsironis@arrikto.com> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: David Woodhouse <dwmw@amazon.co.uk>
2020-11-27KVM: x86: handle !lapic_in_kernel case in kvm_cpu_*_extintPaolo Bonzini2-51/+34
Centralize handling of interrupts from the userspace APIC in kvm_cpu_has_extint and kvm_cpu_get_extint, since userspace APIC interrupts are handled more or less the same as ExtINTs are with split irqchip. This removes duplicated code from kvm_cpu_has_injectable_intr and kvm_cpu_has_interrupt, and makes the code more similar between kvm_cpu_has_{extint,interrupt} on one side and kvm_cpu_get_{extint,interrupt} on the other. Cc: stable@vger.kernel.org Reviewed-by: Filippo Sironi <sironi@amazon.de> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-11-27usb: typec: stusb160x: fix power-opmode property with typec-power-opmodeAmelie Delaunay1-1/+1
Device tree property is named typec-power-opmode, not power-opmode. Fixes: da0cb6310094 ("usb: typec: add support for STUSB160x Type-C controller family") Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20201127131735.28280-1-amelie.delaunay@st.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-27printk: finalize records with trailing newlinesJohn Ogness1-2/+2
Any record with a trailing newline (LOG_NEWLINE flag) cannot be continued because the newline has been stripped and will not be visible if the message is appended. This was already handled correctly when committing in log_output() but was not handled correctly when committing in log_store(). Fixes: f5f022e53b87 ("printk: reimplement log_cont using record extension") Link: https://lore.kernel.org/r/20201126114836.14750-1-john.ogness@linutronix.de Reported-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: John Ogness <john.ogness@linutronix.de> Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Petr Mladek <pmladek@suse.com>
2020-11-27can: af_can: can_rx_unregister(): remove WARN() statement from list ↵Oliver Hartkopp1-2/+5
operation sanity check To detect potential bugs in CAN protocol implementations (double removal of receiver entries) a WARN() statement has been used if no matching list item was found for removal. The fault injection issued by syzkaller was able to create a situation where the closing of a socket runs simultaneously to the notifier call chain for removing the CAN network device in use. This case is very unlikely in real life but it doesn't break anything. Therefore we just replace the WARN() statement with pr_warn() to preserve the notification for the CAN protocol development. Reported-by: syzbot+381d06e0c8eaacb8706f@syzkaller.appspotmail.com Reported-by: syzbot+d0ddd88c9a7432f041e6@syzkaller.appspotmail.com Reported-by: syzbot+76d62d3b8162883c7d11@syzkaller.appspotmail.com Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/r/20201126192140.14350-1-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-27can: m_can: m_can_dev_setup(): add support for bosch mcan version 3.3.0Pankaj Sharma1-0/+2
Add support for mcan bit timing and control mode according to bosch mcan IP version 3.3.0. The mcan version read from the Core Release field of CREL register would be 33. Accordingly the properties are to be set for mcan v3.3.0 Signed-off-by: Pankaj Sharma <pankj.sharma@samsung.com> Link: https://lore.kernel.org/r/1606366302-5520-1-git-send-email-pankj.sharma@samsung.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-27can: m_can: fix nominal bitiming tseg2 min for version >= 3.1Marc Kleine-Budde1-1/+1
At lest the revision 3.3.0 of the bosch m_can IP core specifies that valid register values for "Nominal Time segment after sample point (NTSEG2)" are from 1 to 127. As the hardware uses a value of one more than the programmed value, mean tseg2_min is 2. This patch fixes the tseg2_min value accordingly. Cc: Dan Murphy <dmurphy@ti.com> Cc: Mario Huettel <mario.huettel@gmx.net> Acked-by: Sriram Dash <sriram.dash@samsung.com> Link: https://lore.kernel.org/r/20201124190751.3972238-1-mkl@pengutronix.de Fixes: b03cfc5bb0e1 ("can: m_can: Enable M_CAN version dependent initialization") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-27can: m_can: m_can_open(): remove IRQF_TRIGGER_FALLING from ↵Marc Kleine-Budde1-1/+1
request_threaded_irq()'s flags The threaded IRQ handler is used for the tcan4x5x driver only. The IRQ pin of the tcan4x5x controller is active low, so better not use IRQF_TRIGGER_FALLING when requesting the IRQ. As this can result in missing interrupts. Further, if the device tree specified the interrupt as "IRQ_TYPE_LEVEL_LOW", unloading and reloading of the driver results in the following error during ifup: | irq: type mismatch, failed to map hwirq-31 for gpio@20a8000! | tcan4x5x spi1.1: m_can device registered (irq=0, version=32) | tcan4x5x spi1.1 can2: TCAN4X5X successfully initialized. | tcan4x5x spi1.1 can2: failed to request interrupt This patch fixes the problem by removing the IRQF_TRIGGER_FALLING from the request_threaded_irq(). Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework") Cc: Dan Murphy <dmurphy@ti.com> Cc: Sriram Dash <sriram.dash@samsung.com> Cc: Pankaj Sharma <pankj.sharma@samsung.com> Link: https://lore.kernel.org/r/20201127093548.509253-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-26mm: memcg: relayout structure mem_cgroup to avoid cache interferenceFeng Tang1-14/+14
0day reported one -22.7% regression for will-it-scale page_fault2 case [1] on a 4 sockets 144 CPU platform, and bisected to it to be caused by Waiman's optimization (commit bd0b230fe1) of saving one 'struct page_counter' space for 'struct mem_cgroup'. Initially we thought it was due to the cache alignment change introduced by the patch, but further debug shows that it is due to some hot data members ('vmstats_local', 'vmstats_percpu', 'vmstats') sit in 2 adjacent cacheline (2N and 2N+1 cacheline), and when adjacent cache line prefetch is enabled, it triggers an "extended level" of cache false sharing for 2 adjacent cache lines. So exchange the 2 member blocks, while keeping mostly the original cache alignment, which can restore and even enhance the performance, and save 64 bytes of space for 'struct mem_cgroup' (from 2880 to 2816, with 0day's default RHEL-8.3 kernel config) [1]. https://lore.kernel.org/lkml/20201102091543.GM31092@shao2-debian/ Fixes: bd0b230fe145 ("mm/memcg: unify swap and memsw page counters") Reported-by: kernel test robot <rong.a.chen@intel.com> Signed-off-by: Feng Tang <feng.tang@intel.com> Acked-by: Waiman Long <longman@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-11-26io_uring: fix files grab/cancel racePavel Begunkov1-16/+15
When one task is in io_uring_cancel_files() and another is doing io_prep_async_work() a race may happen. That's because after accounting a request inflight in first call to io_grab_identity() it still may fail and go to io_identity_cow(), which migh briefly keep dangling work.identity and not only. Grab files last, so io_prep_async_work() won't fail if it did get into ->inflight_list. note: the bug shouldn't exist after making io_uring_cancel_files() not poking into other tasks' requests. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-11-26RDMA/hns: Bugfix for memory window mtpt configurationYixian Liu1-0/+1
When a memory window is bound to a memory region, the local write access should be set for its mtpt table. Fixes: c7c28191408b ("RDMA/hns: Add MW support for hip08") Link: https://lore.kernel.org/r/1606386372-21094-1-git-send-email-liweihang@huawei.com Signed-off-by: Yixian Liu <liuyixian@huawei.com> Signed-off-by: Weihang Li <liweihang@huawei.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-11-26RDMA/hns: Fix retry_cnt and rnr_cnt when querying QPWenpeng Liang1-4/+4
The maximum number of retransmission should be returned when querying QP, not the value of retransmission counter. Fixes: 99fcf82521d9 ("RDMA/hns: Fix the wrong value of rnr_retry when querying qp") Fixes: 926a01dc000d ("RDMA/hns: Add QP operations support for hip08 SoC") Link: https://lore.kernel.org/r/1606382977-21431-1-git-send-email-liweihang@huawei.com Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com> Signed-off-by: Weihang Li <liweihang@huawei.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-11-26RDMA/hns: Fix wrong field of SRQ number the device supportsWenpeng Liang1-1/+1
The SRQ capacity is got from the firmware, whose field should be ended at bit 19. Fixes: ba6bb7e97421 ("RDMA/hns: Add interfaces to get pf capabilities from firmware") Link: https://lore.kernel.org/r/1606382812-23636-1-git-send-email-liweihang@huawei.com Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com> Signed-off-by: Weihang Li <liweihang@huawei.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-11-26iommu/vt-d: Don't read VCCAP register unless it existsDavid Woodhouse2-3/+4
My virtual IOMMU implementation is whining that the guest is reading a register that doesn't exist. Only read the VCCAP_REG if the corresponding capability is set in ECAP_REG to indicate that it actually exists. Fixes: 3375303e8287 ("iommu/vt-d: Add custom allocator for IOASID") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Liu Yi L <yi.l.liu@intel.com> Cc: stable@vger.kernel.org # v5.7+ Acked-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/de32b150ffaa752e0cff8571b17dfb1213fbe71c.camel@infradead.org Signed-off-by: Will Deacon <will@kernel.org>
2020-11-26platform/x86: touchscreen_dmi: Add info for the Irbis TW118 tabletHans de Goede1-0/+23
Add touchscreen info for the Irbis TW118 tablet. Reported-and-tested-by: russianneuromancer <russianneuromancer@ya.ru> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20201124110454.114286-1-hdegoede@redhat.com
2020-11-26platform/x86: touchscreen_dmi: Add info for the Predia Basic tabletHans de Goede1-0/+27
Add touchscreen info for the Predia Basic tablet. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201015194949.50566-1-hdegoede@redhat.com
2020-11-26platform/x86: intel-vbtn: Support for tablet mode on HP Pavilion 13 x360 PCMax Verevkin1-0/+6
The Pavilion 13 x360 PC has a chassis-type which does not indicate it is a convertible, while it is actually a convertible. Add it to the dmi_switches_allow_list. Signed-off-by: Max Verevkin <me@maxverevkin.tk> Link: https://lore.kernel.org/r/20201124131652.11165-1-me@maxverevkin.tk Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-11-26platform/x86: toshiba_acpi: Fix the wrong variable assignmentKaixu Xia1-2/+1
The commit 78429e55e4057 ("platform/x86: toshiba_acpi: Clean up variable declaration") cleans up variable declaration in video_proc_write(). Seems it does the variable assignment in the wrong place, this results in dead code and changes the source code logic. Fix it by doing the assignment at the beginning of the funciton. Fixes: 78429e55e4057 ("platform/x86: toshiba_acpi: Clean up variable declaration") Reported-by: Tosk Robot <tencent_os_robot@tencent.com> Signed-off-by: Kaixu Xia <kaixuxia@tencent.com> Link: https://lore.kernel.org/r/1606024177-16481-1-git-send-email-kaixuxia@tencent.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-11-26platform/x86: acer-wmi: add automatic keyboard background light toggle key ↵Timo Witte1-0/+1
as KEY_LIGHTS_TOGGLE Got a dmesg message on my AMD Renoir based Acer laptop: "acer_wmi: Unknown key number - 0x84" when toggling keyboard background light Signed-off-by: Timo Witte <timo.witte@gmail.com> Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com> Link: https://lore.kernel.org/r/20200804001423.36778-1-timo.witte@gmail.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-11-26platform/x86: thinkpad_acpi: Whitelist P15 firmware for dual fan controlMatthias Maier1-0/+1
This commit enables dual fan control for the following new Lenovo models: P15, P15v. Signed-off-by: Matthias Maier <tamiko@43-1.org> Link: https://lore.kernel.org/r/20201126000416.2459645-2-tamiko-ibm-acpi-devel@43-1.org Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-11-26platform/x86: thinkpad_acpi: Send tablet mode switch at wakeup timeBenjamin Berg1-0/+1
The lid state may change while the machine is suspended. As such, we may need to re-check the state at wake-up time (at least when waking up from hibernation). Add the appropriate call to the resume handler in order to sync the SW_TABLET_MODE switch state with the hardware state. Fixes: dda3ec0aa631 ("platform/x86: thinkpad_acpi: Implement tablet mode using GMMS method") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210269 Signed-off-by: Benjamin Berg <bberg@redhat.com> Acked-by: Henrique de Moraes Holschuh <hnh@hmh.eng.br> Link: https://lore.kernel.org/r/20201123132157.866303-1-benjamin@sipsolutions.net Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-11-26platform/x86: thinkpad_acpi: Add BAT1 is primary battery quirk for Thinkpad ↵Hans de Goede1-0/+1
Yoga 11e 4th gen The Thinkpad Yoga 11e 4th gen with the N3450 / Celeron CPU only has one battery which is named BAT1 instead of the expected BAT0, add a quirk for this. This fixes not being able to set the charging tresholds on this model; and this alsoe fixes the following errors in dmesg: ACPI: \_SB_.PCI0.LPCB.EC__.HKEY: BCTG evaluated but flagged as error thinkpad_acpi: Error probing battery 2 battery: extension failed to load: ThinkPad Battery Extension battery: extension unregistered: ThinkPad Battery Extension Note that the added quirk is for the "R0K" BIOS versions which are used on the Thinkpad Yoga 11e 4th gen's with a Celeron CPU, there is a separate "R0L" BIOS for the i3/i5 based versions. This may also need the same quirk, but if that really is necessary is unknown. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20201109103550.16265-1-hdegoede@redhat.com
2020-11-26platform/x86: thinkpad_acpi: Do not report SW_TABLET_MODE on Yoga 11eHans de Goede1-1/+8
The Yoga 11e series has 2 accelerometers described by a BOSC0200 ACPI node. This setup relies on a Windows service which reads both accelerometers and then calculates the angle between the 2 halves to determine laptop / tent / tablet mode and then reports the calculated mode back to the EC by calling special ACPI methods on the BOSC0200 node. The bmc150 iio driver does not support this (it involves double calculations requiring sqrt and arccos so this really needs to be done in userspace), as a result of this on the Yoga 11e the thinkpad_acpi code always reports SW_TABLET_MODE=0, starting with GNOME 3.38 reporting SW_TABLET_MODE=0 causes GNOME to: 1. Not show the onscreen keyboard when a text-input field is focussed with the touchscreen. 2. Disable accelerometer based auto display-rotation. This makes sense when in laptop-mode but not when in tablet-mode. But since for the Yoga 11e the thinkpad_acpi code always reports SW_TABLET_MODE=0, GNOME does not know when the device is in tablet-mode. Stop reporting the broken (always 0) SW_TABLET_MODE on Yoga 11e models to fix this. Note there are plans for userspace to support 360 degree hinges style 2-in-1s with 2 accelerometers and figure out the mode by itself, see: https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/issues/216 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20201106140130.46820-1-hdegoede@redhat.com
2020-11-26platform/x86: thinkpad_acpi: add P1 gen3 second fan supportIakov 'Jake' Kirilenko1-0/+1
Tested on my P1 gen3, works fine with `thinkfan`. Since thinkpad_acpi fan control is off by default, it is safe to add 2nd fan control for brave overclockers Signed-off-by: Iakov 'Jake' Kirilenko <jake.kirilenko@gmail.com> Link: https://lore.kernel.org/r/20201105152556.34073-1-jake.kirilenko@gmail.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-11-26can: mcp251xfd: mcp251xfd_probe(): bail out if no IRQ was givenMarc Kleine-Budde1-0/+4
This patch add a check to the mcp251xfd_probe() function to bail out and give the user a proper error message if no IRQ is specified. Otherwise the driver will probe just fine but ifup will fail with a meaningless "RTNETLINK answers: Invalid argument" error message. Link: https://lore.kernel.org/r/20201123113522.3820052-1-mkl@pengutronix.de Reported-by: Niels Petter <petter@ka-long.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-26can: gs_usb: fix endianess problem with candleLight firmwareMarc Kleine-Budde1-61/+70
The firmware on the original USB2CAN by Geschwister Schneider Technologie Entwicklungs- und Vertriebs UG exchanges all data between the host and the device in host byte order. This is done with the struct gs_host_config::byte_order member, which is sent first to indicate the desired byte order. The widely used open source firmware candleLight doesn't support this feature and exchanges the data in little endian byte order. This breaks if a device with candleLight firmware is used on big endianess systems. To fix this problem, all u32 (but not the struct gs_host_frame::echo_id, which is a transparent cookie) are converted to __le32. Cc: Maximilian Schneider <max@schneidersoft.net> Cc: Hubert Denkmair <hubert@denkmair.de> Reported-by: Michael Rausch <mr@netadair.de> Link: https://lore.kernel.org/r/b58aace7-61f3-6df7-c6df-69fee2c66906@netadair.de Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://lore.kernel.org/r/20201120103818.3386964-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-11-26MAINTAINERS: Adding help for coresight subsystemMathieu Poirier1-1/+3
With the steady stream of new features coming into the subsystem it has been clear for some time now that help is needed. Suzuki and Leo have worked extensively on various parts of the project and have agreed to help. While at it add the new location for the coresight git tree. Acked-by: Leo Yan <leo.yan@linaro.org> Acked-by : Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201125223519.734388-1-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-26media: vidtv.rst: add kernel-doc markupsMauro Carvalho Chehab10-32/+70
Fix existing issues at the kernel-doc markups and add them to the vidtv.rst file. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv.rst: update vidtv documentationMauro Carvalho Chehab1-13/+72
Update the vidtv documentation with the relevant changes after the last patches. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: simplify EIT write functionMauro Carvalho Chehab3-44/+46
- pass struct vidtv_psi_eit_write_args as a pointer; - avoid initializing struct fields multiple times. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: simplify NIT write functionMauro Carvalho Chehab3-48/+47
- pass struct vidtv_psi_nit_write_args as a pointer; - avoid initializing struct fields multiple times. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: simplify SDT write functionMauro Carvalho Chehab3-43/+46
- pass struct vidtv_psi_sdt_write_args as a pointer; - avoid initializing struct fields multiple times. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: cleanup PMT write table functionMauro Carvalho Chehab3-49/+46
- Pass struct vidtv_psi_pmt_write_args as a pointer; - Avoid initializing structs multiple times. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: cleanup PAT write functionMauro Carvalho Chehab3-29/+32
Avoid initializing the structs multiple times and pass the PAT struct as a pointer, instead of a var. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-11-26media: vidtv: cleanup PSI table header functionMauro Carvalho Chehab1-23/+19
- Pass struct header_write_args as a pointer, instead of passing as a var; - Initialize the psi_args struct only once. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>