[PATCH v3 1/2] LICENSE: add GFDL deprecated licenses
There are some files under Documentation which uses deprecated versions of GNU Free Documentation License, on both versions 1.1 and 1.2. On all cases, the license is with no Invariant Sections, Front-Cover Texts or Back-Cover Texts. Add the text file for them, as we'll start using SPDX for those. Signed-off-by: Mauro Carvalho Chehab --- LICENSES/deprecated/GFDL-1.1 | 377 +++ LICENSES/deprecated/GFDL-1.2 | 417 +++ 2 files changed, 794 insertions(+) create mode 100644 LICENSES/deprecated/GFDL-1.1 create mode 100644 LICENSES/deprecated/GFDL-1.2 diff --git a/LICENSES/deprecated/GFDL-1.1 b/LICENSES/deprecated/GFDL-1.1 new file mode 100644 index ..ae62699ab62c --- /dev/null +++ b/LICENSES/deprecated/GFDL-1.1 @@ -0,0 +1,377 @@ +Valid-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later +Valid-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-only +Valid-License-Identifier: GFDL-1.1-no-invariants-or-later +Valid-License-Identifier: GFDL-1.1-no-invariants-only +SPDX-URL: https://spdx.org/licenses/GFDL-1.1-no-invariants-or-later.html +Usage-Guide: + The GNU Free Documentation License should only be used without + Invariant Sections, Front-Cover Texts or Back-Cover Texts. + It should not be used for new documents, except when they are + part of sections that are already using it (notably, the + userspace-api media documentation). + To use the license in source code, put the following SPDX tag/value pair + into a comment according to the placement guidelines in the licensing + rules documentation: +SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later + or +SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-only + or +SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later + or +SPDX-License-Identifier: GFDL-1.1-no-invariants-only +License-Text: +GNU Free Documentation License + Version 1.1, March 2000 + + Copyright (C) 2000 Free Software Foundation, Inc. + 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + +0. PREAMBLE + +The purpose of this License is to make a manual, textbook, or other +written document "free" in the sense of freedom: to assure everyone +the effective freedom to copy and redistribute it, with or without +modifying it, either commercially or noncommercially. Secondarily, +this License preserves for the author and publisher a way to get +credit for their work, while not being considered responsible for +modifications made by others. + +This License is a kind of "copyleft", which means that derivative +works of the document must themselves be free in the same sense. It +complements the GNU General Public License, which is a copyleft +license designed for free software. + +We have designed this License in order to use it for manuals for free +software, because free software needs free documentation: a free +program should come with manuals providing the same freedoms that the +software does. But this License is not limited to software manuals; +it can be used for any textual work, regardless of subject matter or +whether it is published as a printed book. We recommend this License +principally for works whose purpose is instruction or reference. + + +1. APPLICABILITY AND DEFINITIONS + +This License applies to any manual or other work that contains a +notice placed by the copyright holder saying it can be distributed +under the terms of this License. The "Document", below, refers to any +such manual or work. Any member of the public is a licensee, and is +addressed as "you". + +A "Modified Version" of the Document means any work containing the +Document or a portion of it, either copied verbatim, or with +modifications and/or translated into another language. + +A "Secondary Section" is a named appendix or a front-matter section of +the Document that deals exclusively with the relationship of the +publishers or authors of the Document to the Document's overall subject +(or to related matters) and contains nothing that could fall directly +within that overall subject. (For example, if the Document is in part a +textbook of mathematics, a Secondary Section may not explain any +mathematics.) The relationship could be a matter of historical +connection with the subject or with related matters, or of legal, +commercial, philosophical, ethical or political position regarding +them. + +The "Invariant Sections" are certain Secondary Sections whose titles +are designated, as being those of Invariant Sections, in the notice +that says that the Document is released under this License. + +The "Cover Texts" are certain short passages of text that are listed, +as Front-Cover Texts or Back-Cover Texts, in the notice that says that +the Document is released under this License. + +A "Transparent"
[PATCH v2] Documentation: kunit: Add naming guidelines
As discussed in [1], KUnit tests have hitherto not had a particularly consistent naming scheme. This adds documentation outlining how tests and test suites should be named, including how those names should be used in Kconfig entries and filenames. [1]: https://lore.kernel.org/linux-kselftest/202006141005.BA19A9D3@keescook/t/#u Signed-off-by: David Gow Reviewed-by: Kees Cook Reviewed-by: Brendan Higgins --- This is v2 of the KUnit test nomenclature guidelines. The guidelines have changed a bit in response to the discussion on the v1 thread which came about after plumbers. The major change is that the filename suffix is now "_test", with "_kunit" permitted where it conflicts. There are also some other exceptions carved out around existing tests, and very non-unit-like tests. Changelog: v2: - Rewrote the filename section to use "_test" as a suffix, and focus on module names, not filenames. - Add a motivating introduction, which also calls out existing tests and tests which cause problems when run automatically (long running, flaky tests) as reasons to avoid the guidelines. - Talk about including the type of test in the suite name, but only if theres an actual confict. (And update the example for this). v1: https://lore.kernel.org/linux-kselftest/20200702071416.1780522-1-david...@google.com/ - Fixed a bit of space/tab confusion in the index (Thanks, Randy) - Added some more examples (and some test case examples). - Added some examples of what not to call subsystems and suites. - No longer explicitly require "If unsure, put N" in Kconfig entries. - Minor formatting changes RFC: https://lore.kernel.org/linux-kselftest/20200620054944.167330-1-david...@google.com/T/#u - Initial version The result is a little bit weaker than the previous versions, but hopefully will let us get the areas we agree on down. -- David Documentation/dev-tools/kunit/index.rst | 1 + Documentation/dev-tools/kunit/style.rst | 207 2 files changed, 208 insertions(+) create mode 100644 Documentation/dev-tools/kunit/style.rst diff --git a/Documentation/dev-tools/kunit/index.rst b/Documentation/dev-tools/kunit/index.rst index e93606ecfb01..c234a3ab3c34 100644 --- a/Documentation/dev-tools/kunit/index.rst +++ b/Documentation/dev-tools/kunit/index.rst @@ -11,6 +11,7 @@ KUnit - Unit Testing for the Linux Kernel usage kunit-tool api/index + style faq What is KUnit? diff --git a/Documentation/dev-tools/kunit/style.rst b/Documentation/dev-tools/kunit/style.rst new file mode 100644 index ..c001ea1cd87d --- /dev/null +++ b/Documentation/dev-tools/kunit/style.rst @@ -0,0 +1,207 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +Test Style and Nomenclature +=== + +To make finding, writing, and using KUnit tests as simple as possible, it's +strongly encouraged that they are named and written according to the guidelines +below. While it's possible to write KUnit tests which do not follow these rules, +they may break some tooling, may conflict with other tests, and may not be run +automatically by testing systems. + +It's recommended that you only deviate from these guidelines when: + +1. Porting tests to KUnit which are already known with an existing name, or +2. Writing tests which would cause serious problems if automatically run (e.g., + nonderministically producing false positives or negatives, or taking an + extremely long time to run). + +Subsystems, Suites, and Tests += + +In order to make tests as easy to find as possible, they're grouped into suites +and subsystems. A test suite is a group of tests which test a related area of +the kernel, and a subsystem is a set of test suites which test different parts +of the same kernel subsystem or driver. + +Subsystems +-- + +Every test suite must belong to a subsystem. A subsystem is a collection of one +or more KUnit test suites which test the same driver or part of the kernel. A +rule of thumb is that a test subsystem should match a single kernel module. If +the code being tested can't be compiled as a module, in many cases the subsystem +should correspond to a directory in the source tree or an entry in the +MAINTAINERS file. If unsure, follow the conventions set by tests in similar +areas. + +Test subsystems should be named after the code being tested, either after the +module (wherever possible), or after the directory or files being tested. Test +subsystems should be named to avoid ambiguity where necessary. + +If a test subsystem name has multiple components, they should be separated by +underscores. *Do not* include "test" or "kunit" directly in the subsystem name +unless you are actually testing other tests or the kunit framework itself. + +Example subsystems could be: + +``ext4`` + Matches the module and filesystem name. +``apparmor`` + Matches the module name and LSM name. +``kasan`` + Common name
[PATCH v2] mailbox: sti: fix struct description warnings
Fix formating of struct description to avoid warning highlighted
by W=1 compilation.
Signed-off-by: Alain Volmat
---
v2: fixes tag removed
drivers/mailbox/mailbox-sti.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mailbox/mailbox-sti.c b/drivers/mailbox/mailbox-sti.c
index 2baf69a0b81c..0f2bc09c364d 100644
--- a/drivers/mailbox/mailbox-sti.c
+++ b/drivers/mailbox/mailbox-sti.c
@@ -36,7 +36,7 @@
#define MBOX_BASE(mdev, inst) ((mdev)->base + ((inst) * 4))
/**
- * STi Mailbox device data
+ * struct sti_mbox_device - STi Mailbox device data
*
* An IP Mailbox is currently composed of 4 instances
* Each instance is currently composed of 32 channels
@@ -60,7 +60,7 @@ struct sti_mbox_device {
};
/**
- * STi Mailbox platform specific configuration
+ * struct sti_mbox_pdata - STi Mailbox platform specific configuration
*
* @num_inst: Maximum number of instances in one HW Mailbox
* @num_chan: Maximum number of channel per instance
@@ -71,7 +71,7 @@ struct sti_mbox_pdata {
};
/**
- * STi Mailbox allocated channel information
+ * struct sti_channel - STi Mailbox allocated channel information
*
* @mdev: Pointer to parent Mailbox device
* @instance: Instance number channel resides in
--
2.17.1
Re: [PATCH v2 6/7] xen/balloon: try to merge system ram resources
On 08.09.20 22:10, David Hildenbrand wrote: Let's try to merge system ram resources we add, to minimize the number of resources in /proc/iomem. We don't care about the boundaries of individual chunks we added. Cc: Andrew Morton Cc: Michal Hocko Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Stefano Stabellini Cc: Roger Pau Monné Cc: Julien Grall Cc: Pankaj Gupta Cc: Baoquan He Cc: Wei Yang Signed-off-by: David Hildenbrand Reviewed-by: Juergen Gross Juergen --- drivers/xen/balloon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 7bac38764513d..b57b2067ecbfb 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -331,7 +331,7 @@ static enum bp_state reserve_additional_memory(void) mutex_unlock(_mutex); /* add_memory_resource() requires the device_hotplug lock */ lock_device_hotplug(); - rc = add_memory_resource(nid, resource, 0); + rc = add_memory_resource(nid, resource, MEMHP_MERGE_RESOURCE); unlock_device_hotplug(); mutex_lock(_mutex);
Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
On 08.09.20 22:10, David Hildenbrand wrote:
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.
This patch is based on a similar patch by Oscar Salvador:
https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de
Acked-by: Wei Liu
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Dan Williams
Cc: Jason Gunthorpe
Cc: Pankaj Gupta
Cc: Baoquan He
Cc: Wei Yang
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Greg Kroah-Hartman
Cc: Vishal Verma
Cc: Dave Jiang
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Wei Liu
Cc: Heiko Carstens
Cc: Vasily Gorbik
Cc: Christian Borntraeger
Cc: David Hildenbrand
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: "Oliver O'Halloran"
Cc: Pingfan Liu
Cc: Nathan Lynch
Cc: Libor Pechacek
Cc: Anton Blanchard
Cc: Leonardo Bras
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-a...@vger.kernel.org
Cc: linux-nvd...@lists.01.org
Cc: linux-hyp...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: xen-de...@lists.xenproject.org
Signed-off-by: David Hildenbrand
Reviewed-by: Juergen Gross (Xen related part)
Juergen
---
arch/powerpc/platforms/powernv/memtrace.c | 2 +-
arch/powerpc/platforms/pseries/hotplug-memory.c | 2 +-
drivers/acpi/acpi_memhotplug.c | 2 +-
drivers/base/memory.c | 2 +-
drivers/dax/kmem.c | 2 +-
drivers/hv/hv_balloon.c | 2 +-
drivers/s390/char/sclp_cmd.c| 2 +-
drivers/virtio/virtio_mem.c | 2 +-
drivers/xen/balloon.c | 2 +-
include/linux/memory_hotplug.h | 10 ++
mm/memory_hotplug.c | 15 ---
11 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/memtrace.c
b/arch/powerpc/platforms/powernv/memtrace.c
index 13b369d2cc454..a7475d18c671c 100644
--- a/arch/powerpc/platforms/powernv/memtrace.c
+++ b/arch/powerpc/platforms/powernv/memtrace.c
@@ -224,7 +224,7 @@ static int memtrace_online(void)
ent->mem = 0;
}
- if (add_memory(ent->nid, ent->start, ent->size)) {
+ if (add_memory(ent->nid, ent->start, ent->size, 0)) {
pr_err("Failed to add trace memory to node %d\n",
ent->nid);
ret += 1;
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 5d545b78111f9..54a888ea7f751 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -606,7 +606,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
block_sz = memory_block_size_bytes();
/* Add the memory */
- rc = __add_memory(lmb->nid, lmb->base_addr, block_sz);
+ rc = __add_memory(lmb->nid, lmb->base_addr, block_sz, 0);
if (rc) {
invalidate_lmb_associativity_index(lmb);
return rc;
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index e294f44a78504..d91b3584d4b2b 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -207,7 +207,7 @@ static int acpi_memory_enable_device(struct
acpi_memory_device *mem_device)
if (node < 0)
node = memory_add_physaddr_to_nid(info->start_addr);
- result = __add_memory(node, info->start_addr, info->length);
+ result = __add_memory(node, info->start_addr, info->length, 0);
/*
* If the memory block has been used by the kernel, add_memory()
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 4db3c660de831..2287bcf86480e 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -432,7 +432,7 @@ static ssize_t probe_store(struct device *dev, struct
device_attribute *attr,
nid = memory_add_physaddr_to_nid(phys_addr);
ret = __add_memory(nid, phys_addr,
- MIN_MEMORY_BLOCK_SIZE * sections_per_block);
+ MIN_MEMORY_BLOCK_SIZE * sections_per_block, 0);
if (ret)
goto out;
diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index 7dcb2902e9b1b..8e66b28ef5bc6 100644
--- a/drivers/dax/kmem.c
+++ b/drivers/dax/kmem.c
@@ -95,7 +95,7 @@ int dev_dax_kmem_probe(struct dev_dax *dev_dax)
* this as RAM automatically.
*/
rc = add_memory_driver_managed(numa_node, range.start,
- range_len(), kmem_name);
+ range_len(), kmem_name, 0);
res->flags |= IORESOURCE_BUSY;
if (rc) {
Re: [RFC PATCH 1/2] lib/string: Disable instrumentation
On Tue, Sep 8, 2020 at 8:40 PM Arvind Sankar wrote: > > On Tue, Sep 08, 2020 at 10:21:32AM -0700, Kees Cook wrote: > > On Tue, Sep 08, 2020 at 11:39:11AM +0200, Marco Elver wrote: > > > On Sun, 6 Sep 2020 at 00:23, Arvind Sankar wrote: > > > > > > > > String functions can be useful in early boot, but using instrumented > > > > versions can be problematic: eg on x86, some of the early boot code is > > > > executing out of an identity mapping rather than the kernel virtual > > > > addresses. Accessing any global variables at this point will lead to a > > > > crash. > > > > > > > > > > Ouch. > > > > > > We have found manifestations of bugs in lib/string.c functions, e.g.: > > > > > > https://groups.google.com/forum/#!msg/syzkaller-bugs/atbKWcFqE9s/x7AtoVoBAgAJ > > > > > > https://groups.google.com/forum/#!msg/syzkaller-bugs/iGBUm-FDhkM/chl05uEgBAAJ > > > > > > Is there any way this can be avoided? > > > > Agreed: I would like to keep this instrumentation; it's a common place > > to find bugs, security issues, etc. > > > > -- > > Kees Cook > > Ok, understood. I'll revise to open-code the strscpy instead. > > Is instrumentation supported on x86-32? load_ucode_bsp() on 32-bit is > called before paging is enabled, and load_ucode_bsp() itself, along with > eg lib/earlycpio and lib/string that it uses, don't have anything to > disable instrumentation. kcov, kasan, kcsan are unsupported already on > 32-bit, but the others like gcov and PROFILE_ALL_BRANCHES look like they > would just cause a crash if microcode loading is enabled. I agree we should not disable instrumentation of such common functions. Instead of open-coding these functions maybe we could produce both instrumented and non-instrumented versions from the same source implementation. Namely, place implementation in a header function with always_inline attribute and include it from 2 source files, one with instrumentation enabled and another with instrumentation disabled. This way we could produce strscpy (instrumented) and __strscpy (non-instrumented) from the same source.
Re: [PATCH v5 00/21] kprobes: Unify kretprobe trampoline handlers and make kretprobe lockless
On Wed, 9 Sep 2020 00:09:23 +0900 Masami Hiramatsu wrote: > > > Of course make it lockless then warning is gone. > > > But even without the lockless patch, this warning can be false-positive > > > because we prohibit nested kprobe call, right? > > > > Yes, because the actual nesting is avoided by kprobe_busy, but lockdep > > can't tell. Lockdep sees a regular lock user and an in-nmi lock user and > > figures that's a bad combination. Hmm, what about introducing new LOCK_USED_KPROBE bit, which will be set if the lock is accessed when the current_kprobe is set (including kprobe_busy)? This means it is in the kprobe user-handler context. If we access the lock always in the kprobes context, it is never nested. Thank you, -- Masami Hiramatsu
INFO: rcu detected stall in cleanup_net (4)
Hello,
syzbot found the following issue on:
HEAD commit:59126901 Merge tag 'perf-tools-fixes-for-v5.9-2020-09-03' ..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12edb93590
kernel config: https://syzkaller.appspot.com/x/.config?x=3c5f6ce8d5b68299
dashboard link: https://syzkaller.appspot.com/bug?extid=8267241609ae8c23b248
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=157c7aa590
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13c92ef990
The issue was bisected to:
commit 5a781ccbd19e4664babcbe4b4ead7aa2b9283d22
Author: Vinicius Costa Gomes
Date: Sat Sep 29 00:59:43 2018 +
tc: Add support for configuring the taprio scheduler
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12f2424590
console output: https://syzkaller.appspot.com/x/log.txt?x=16f2424590
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8267241609ae8c23b...@syzkaller.appspotmail.com
Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler")
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu:1-...0: (1 GPs behind) idle=2e2/1/0x4000 softirq=8639/8646
fqs=5250
(detected by 0, t=10502 jiffies, g=10573, q=113)
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 2516 Comm: kworker/u4:4 Not tainted 5.9.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Workqueue: netns cleanup_net
RIP: 0010:__rb_erase_augmented include/linux/rbtree_augmented.h:201 [inline]
RIP: 0010:rb_erase+0x0/0x1210 lib/rbtree.c:443
Code: 08 4c 8b 04 24 e9 1f f6 ff ff e8 fb f1 00 fe 48 8b 54 24 08 4c 8b 04 24
e9 f7 f5 ff ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 <48> b8 00 00 00 00 00 fc
ff df 41 57 49 89 f7 41 56 41 55 49 89 fd
RSP: 0018:c9da8db8 EFLAGS: 0046
RAX: 00010002 RBX: 88808ed3fb40 RCX: 111015ce4f13
RDX: 88809fb66540 RSI: 8880ae727890 RDI: 88808ed3fb40
RBP: 8880ae727890 R08: R09: 8ab2640f
R10: 888099a68400 R11: 0001 R12: 8880ae727898
R13: 8880ae727840 R14: 88808ed3fb40 R15: dc00
FS: () GS:8880ae70() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 2610 CR3: 09a8d000 CR4: 001506e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
rb_erase_cached include/linux/rbtree.h:149 [inline]
timerqueue_del+0x7f/0x140 lib/timerqueue.c:67
__remove_hrtimer kernel/time/hrtimer.c:1001 [inline]
__run_hrtimer kernel/time/hrtimer.c:1504 [inline]
__hrtimer_run_queues+0x518/0xfc0 kernel/time/hrtimer.c:1588
hrtimer_interrupt+0x32a/0x930 kernel/time/hrtimer.c:1650
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1080 [inline]
__sysvec_apic_timer_interrupt+0x142/0x5e0 arch/x86/kernel/apic/apic.c:1097
asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:706
__run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline]
run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline]
sysvec_apic_timer_interrupt+0xb2/0xf0 arch/x86/kernel/apic/apic.c:1091
asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:581
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:770 [inline]
RIP: 0010:console_unlock+0xb4a/0xe60 kernel/printk/printk.c:2509
Code: 89 48 c1 e8 03 42 80 3c 38 00 0f 85 18 03 00 00 48 83 3d a0 f8 58 08 00
0f 84 90 01 00 00 e8 4d 07 17 00 48 8b 7c 24 30 57 9d <0f> 1f 44 00 00 8b 5c 24
64 31 ff 89 de e8 b4 03 17 00 85 db 0f 84
RSP: 0018:c90008797280 EFLAGS: 0293
RAX: RBX: 0200 RCX: 0006
RDX: 88809fb66540 RSI: 815d43b3 RDI: 0293
RBP: R08: 0001 R09: 8c5f49e7
R10: fbfff18be93c R11: 000808e8 R12: 84c29820
R13: 0073 R14: 8a3cb4b0 R15: dc00
vprintk_emit+0x2ff/0x740 kernel/printk/printk.c:2029
dev_vprintk_emit+0x3eb/0x436 drivers/base/core.c:4133
dev_printk_emit+0xba/0xf1 drivers/base/core.c:4144
__netdev_printk+0x1c6/0x27a net/core/dev.c:10749
netdev_info+0xd7/0x109 net/core/dev.c:10804
nsim_udp_tunnel_unset_port.cold+0x179/0x1c8
drivers/net/netdevsim/udp_tunnels.c:59
udp_tunnel_nic_device_sync_one net/ipv4/udp_tunnel_nic.c:224 [inline]
udp_tunnel_nic_device_sync_by_port net/ipv4/udp_tunnel_nic.c:245 [inline]
__udp_tunnel_nic_device_sync.part.0+0xa50/0xcb0 net/ipv4/udp_tunnel_nic.c:288
__udp_tunnel_nic_device_sync net/ipv4/udp_tunnel_nic.c:282 [inline]
udp_tunnel_nic_flush+0x24c/0x560 net/ipv4/udp_tunnel_nic.c:665
udp_tunnel_nic_unregister net/ipv4/udp_tunnel_nic.c:791 [inline]
udp_tunnel_nic_netdevice_event+0x7c5/0xfcf
[PATCH] iommu/dma: Fix IOVA reserve dma ranges
Fix IOVA reserve failure for memory regions listed in dma-ranges in the
following cases.
- start address of memory region is 0x0.
- end address of a memory region is equal to start address of next memory
region.
Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA
address")
Signed-off-by: Srinath Mannam
---
drivers/iommu/dma-iommu.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 5141d49a046b..0a3f67a4f9ae 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -213,14 +213,21 @@ static int iova_reserve_pci_windows(struct pci_dev *dev,
resource_list_for_each_entry(window, >dma_ranges) {
end = window->res->start - window->offset;
resv_iova:
+ if (end < start) {
+ /* dma_ranges list should be sorted */
+ dev_err(>dev, "Failed to reserve IOVA\n");
+ return -EINVAL;
+ }
+ /*
+* Skip the cases when start address of first memory region is
+* 0x0 and end address of one memory region and start address
+* of next memory region are equal. Reserve IOVA for rest of
+* addresses fall in between given memory ranges.
+*/
if (end > start) {
lo = iova_pfn(iovad, start);
hi = iova_pfn(iovad, end);
reserve_iova(iovad, lo, hi);
- } else {
- /* dma_ranges list should be sorted */
- dev_err(>dev, "Failed to reserve IOVA\n");
- return -EINVAL;
}
start = window->res->end - window->offset + 1;
--
2.17.1
[rcu:rcu/next] BUILD SUCCESS d3f3d87569786ca7c672fe75af446ab346455682
randconfig-a001-20200907 x86_64 randconfig-a002-20200907 i386 randconfig-a004-20200908 i386 randconfig-a005-20200908 i386 randconfig-a006-20200908 i386 randconfig-a002-20200908 i386 randconfig-a001-20200908 i386 randconfig-a003-20200908 i386 randconfig-a004-20200907 i386 randconfig-a005-20200907 i386 randconfig-a006-20200907 i386 randconfig-a002-20200907 i386 randconfig-a003-20200907 i386 randconfig-a001-20200907 i386 randconfig-a004-20200909 i386 randconfig-a005-20200909 i386 randconfig-a006-20200909 i386 randconfig-a002-20200909 i386 randconfig-a001-20200909 i386 randconfig-a003-20200909 x86_64 randconfig-a013-20200908 x86_64 randconfig-a016-20200908 x86_64 randconfig-a011-20200908 x86_64 randconfig-a012-20200908 x86_64 randconfig-a015-20200908 x86_64 randconfig-a014-20200908 i386 randconfig-a016-20200907 i386 randconfig-a015-20200907 i386 randconfig-a011-20200907 i386 randconfig-a013-20200907 i386 randconfig-a014-20200907 i386 randconfig-a012-20200907 i386 randconfig-a016-20200908 i386 randconfig-a015-20200908 i386 randconfig-a011-20200908 i386 randconfig-a013-20200908 i386 randconfig-a014-20200908 i386 randconfig-a012-20200908 i386 randconfig-a016-20200909 i386 randconfig-a015-20200909 i386 randconfig-a011-20200909 i386 randconfig-a013-20200909 i386 randconfig-a014-20200909 i386 randconfig-a012-20200909 riscvallyesconfig riscv allnoconfig riscvallmodconfig riscv defconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a004-20200908 x86_64 randconfig-a006-20200908 x86_64 randconfig-a003-20200908 x86_64 randconfig-a001-20200908 x86_64 randconfig-a005-20200908 x86_64 randconfig-a002-20200908 x86_64 randconfig-a013-20200909 x86_64 randconfig-a016-20200909 x86_64 randconfig-a011-20200909 x86_64 randconfig-a012-20200909 x86_64 randconfig-a015-20200909 x86_64 randconfig-a014-20200909 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [ANNOUNCE] v5.9-rc3-rt3
On Wed, 2020-09-09 at 05:12 +0200, Mike Galbraith wrote: > On Wed, 2020-09-02 at 17:55 +0200, Sebastian Andrzej Siewior wrote: > > > > Known issues > > - It has been pointed out that due to changes to the printk code the > >internal buffer representation changed. This is only an issue if > > tools > >like `crash' are used to extract the printk buffer from a kernel > > memory > >image. > > Ouch. While installing -rt5 on lappy via nfs, -rt5 server box exploded > leaving nada in logs. I have a nifty crash dump of the event, but... After convincing crash (with club) that it didn't _really_ need a log_buf, nfs had nothing to do with the crash, it was nouveau. KERNEL: vmlinux-5.9.0.gf4d51df-rt5-rt.gz DUMPFILE: vmcore CPUS: 8 DATE: Wed Sep 9 04:41:24 2020 UPTIME: 00:08:10 LOAD AVERAGE: 3.17, 1.86, 0.99 TASKS: 715 NODENAME: homer RELEASE: 5.9.0.gf4d51df-rt5-rt VERSION: #1 SMP PREEMPT_RT Wed Sep 9 03:22:01 CEST 2020 MACHINE: x86_64 (3591 Mhz) MEMORY: 16 GB PANIC: "" PID: 2146 COMMAND: "X" TASK: 994c7fad [THREAD_INFO: 994c7fad] CPU: 0 STATE: TASK_RUNNING (PANIC) crash> bt -l PID: 2146 TASK: 994c7fad CPU: 0 COMMAND: "X" #0 [bfffc11a76c8] machine_kexec at b7064879 /backup/usr/local/src/kernel/linux-master-rt/./include/linux/ftrace.h: 792 #1 [bfffc11a7710] __crash_kexec at b7173622 /backup/usr/local/src/kernel/linux-master-rt/kernel/kexec_core.c: 963 #2 [bfffc11a77d0] crash_kexec at b7174920 /backup/usr/local/src/kernel/linux-master-rt/./arch/x86/include/asm/atomic.h: 41 #3 [bfffc11a77e0] oops_end at b702716f /backup/usr/local/src/kernel/linux-master-rt/arch/x86/kernel/dumpstack.c: 342 #4 [bfffc11a7800] exc_general_protection at b79a2fc6 /backup/usr/local/src/kernel/linux-master-rt/arch/x86/kernel/traps.c: 82 #5 [bfffc11a7890] asm_exc_general_protection at b7a00a1e /backup/usr/local/src/kernel/linux-master-rt/./arch/x86/include/asm/idtentry.h: 532 #6 [bfffc11a78a0] nvif_object_ctor at c07ee6a7 [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nvif/object.c: 280 #7 [bfffc11a7918] __kmalloc at b72eea12 /backup/usr/local/src/kernel/linux-master-rt/mm/slub.c: 261 #8 [bfffc11a7980] nvif_object_ctor at c07ee6a7 [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nvif/object.c: 280 #9 [bfffc11a79d0] nvif_mem_ctor_type at c07eef48 [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nvif/mem.c: 74 #10 [bfffc11a7aa8] nouveau_mem_vram at c08b5291 [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nouveau_mem.c: 155 #11 [bfffc11a7b10] nouveau_vram_manager_new at c08b594d [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nouveau_ttm.c: 76 #12 [bfffc11a7b30] ttm_bo_mem_space at c05af2ac [ttm] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/ttm/ttm_bo.c: 1065 #13 [bfffc11a7b88] ttm_bo_validate at c05afaca [ttm] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/ttm/ttm_bo.c: 1137 #14 [bfffc11a7c18] ttm_bo_init_reserved at c05afe70 [ttm] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/ttm/ttm_bo.c: 1330 #15 [bfffc11a7c60] ttm_bo_init at c05afff7 [ttm] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/ttm/ttm_bo.c: 1364 #16 [bfffc11a7cc8] nouveau_bo_init at c08b0f7b [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nouveau_bo.c: 317 #17 [bfffc11a7d38] nouveau_gem_new at c08b2f7b [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nouveau_gem.c: 206 #18 [bfffc11a7d70] nouveau_gem_ioctl_new at c08b3001 [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nouveau_gem.c: 272 #19 [bfffc11a7da0] drm_ioctl_kernel at c066f564 [drm] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/drm_ioctl.c: 793 #20 [bfffc11a7de0] drm_ioctl at c066f88e [drm] /backup/usr/local/src/kernel/linux-master-rt/./include/linux/uaccess.h: 168 #21 [bfffc11a7ed0] nouveau_drm_ioctl at c08abf56 [nouveau] /backup/usr/local/src/kernel/linux-master-rt/drivers/gpu/drm/nouveau/nouveau_drm.c: 1163 #22 [bfffc11a7f08] __x64_sys_ioctl at b733255e /backup/usr/local/src/kernel/linux-master-rt/fs/ioctl.c: 49 #23 [bfffc11a7f40] do_syscall_64 at b79a25c3 /backup/usr/local/src/kernel/linux-master-rt/arch/x86/entry/common.c: 46 #24 [bfffc11a7f50] entry_SYSCALL_64_after_hwframe at b7a0008c
Re: [BUG RT] dump-capture kernel not executed for panic in interrupt context
Hi,
here is the new version of the patch based on Peters suggestion
It looks like it works fine. I added the BUG_ON to __crash_kexec,
because it is a precondition, that panic_cpu is set correctly, otherwise
the whole locking logic fails.
The mutex_trylock can still be used, because it is only in syscall
context and no interrupt context.
Jörg
---
kernel/kexec.c | 8 ++--
kernel/kexec_core.c | 86 +++--
kernel/kexec_file.c | 4 +-
kernel/kexec_internal.h | 6 ++-
4 files changed, 69 insertions(+), 35 deletions(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index f977786fe498..118a012aeac2 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -255,12 +255,12 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry,
unsigned long, nr_segments,
*
* KISS: always take the mutex.
*/
- if (!mutex_trylock(_mutex))
+ if (!kexec_trylock())
return -EBUSY;
result = do_kexec_load(entry, nr_segments, segments, flags);
- mutex_unlock(_mutex);
+ kexec_unlock();
return result;
}
@@ -309,12 +309,12 @@ COMPAT_SYSCALL_DEFINE4(kexec_load, compat_ulong_t,
entry,
*
* KISS: always take the mutex.
*/
- if (!mutex_trylock(_mutex))
+ if (!kexec_trylock())
return -EBUSY;
result = do_kexec_load(entry, nr_segments, ksegments, flags);
- mutex_unlock(_mutex);
+ kexec_unlock();
return result;
}
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index c19c0dad1ebe..71682a33b1ba 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -45,7 +45,7 @@
#include
#include "kexec_internal.h"
-DEFINE_MUTEX(kexec_mutex);
+static DEFINE_MUTEX(kexec_mutex);
/* Per cpu memory for storing cpu states in case of system crash. */
note_buf_t __percpu *crash_notes;
@@ -70,6 +70,43 @@ struct resource crashk_low_res = {
.desc = IORES_DESC_CRASH_KERNEL
};
+void kexec_lock(void)
+{
+ /*
+ * LOCK kexec_mutex cmpxchg(_cpu, INVALID, cpu)
+ * MB MB
+ * panic_cpu == INVALID kexec_mutex == LOCKED
+ *
+ * Ensures either we observe the cmpxchg, or crash_kernel() observes
+ * our lock acquisition.
+ */
+ mutex_lock(_mutex);
+ smp_mb();
+ atomic_cond_read_acquire(_cpu, VAL == PANIC_CPU_INVALID);
+}
+
+int kexec_trylock(void) {
+ if (!mutex_trylock(_mutex)) {
+ return 0;
+ }
+ smp_mb();
+ if (atomic_read(_cpu) != PANIC_CPU_INVALID) {
+ mutex_unlock(_mutex);
+ return 0;
+ }
+ return 1;
+}
+
+void kexec_unlock(void)
+{
+ mutex_unlock(_mutex);
+}
+
+int kexec_is_locked(void)
+{
+ return mutex_is_locked(_mutex);
+}
+
int kexec_should_crash(struct task_struct *p)
{
/*
@@ -943,24 +980,15 @@ int kexec_load_disabled;
*/
void __noclone __crash_kexec(struct pt_regs *regs)
{
- /* Take the kexec_mutex here to prevent sys_kexec_load
- * running on one cpu from replacing the crash kernel
- * we are using after a panic on a different cpu.
- *
- * If the crash kernel was not located in a fixed area
- * of memory the xchg(_crash_image) would be
- * sufficient. But since I reuse the memory...
- */
- if (mutex_trylock(_mutex)) {
- if (kexec_crash_image) {
- struct pt_regs fixed_regs;
-
- crash_setup_regs(_regs, regs);
- crash_save_vmcoreinfo();
- machine_crash_shutdown(_regs);
- machine_kexec(kexec_crash_image);
- }
- mutex_unlock(_mutex);
+ BUG_ON(atomic_read(_cpu) != raw_smp_processor_id());
+
+ if (!kexec_is_locked() && kexec_crash_image) {
+ struct pt_regs fixed_regs;
+
+ crash_setup_regs(_regs, regs);
+ crash_save_vmcoreinfo();
+ machine_crash_shutdown(_regs);
+ machine_kexec(kexec_crash_image);
}
}
STACK_FRAME_NON_STANDARD(__crash_kexec);
@@ -977,9 +1005,11 @@ void crash_kexec(struct pt_regs *regs)
this_cpu = raw_smp_processor_id();
old_cpu = atomic_cmpxchg(_cpu, PANIC_CPU_INVALID, this_cpu);
if (old_cpu == PANIC_CPU_INVALID) {
- /* This is the 1st CPU which comes here, so go ahead. */
- printk_safe_flush_on_panic();
- __crash_kexec(regs);
+ if (!kexec_is_locked()) {
+ /* This is the 1st CPU which comes here, so go ahead. */
+ printk_safe_flush_on_panic();
+ __crash_kexec(regs);
+ }
/*
* Reset panic_cpu to allow another panic()/crash_kexec()
@@ -993,10 +1023,10 @@ size_t crash_get_memory_size(void)
{
size_t size = 0;
- mutex_lock(_mutex);
+ kexec_lock();
if (crashk_res.end != crashk_res.start)
size = resource_size(_res);
- mutex_unlock(_mutex);
+ kexec_unlock();
return size;
}
@@ -1016,7 +1046,7 @@ int crash_shrink_memory(unsigned long new_size)
unsigned long old_size;
struct resource *ram_res;
- mutex_lock(_mutex);
+ kexec_lock();
if
linux-next: build failure after merge of the driver-core tree
Hi all,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
lib/test_firmware.c: In function 'trigger_request_platform_store':
lib/test_firmware.c:517:35: error: 'efi_embedded_fw_list' undeclared (first use
in this function); did you mean 'efi_embedded_fw_desc'?
517 | list_add(_embedded_fw.list, _embedded_fw_list);
| ^~~~
| efi_embedded_fw_desc
lib/test_firmware.c:517:35: note: each undeclared identifier is reported only
once for each function it appears in
lib/test_firmware.c:518:34: error: 'efi_embedded_fw_checked' undeclared (first
use in this function); did you mean 'saved_efi_embedded_fw_checked'?
518 | saved_efi_embedded_fw_checked = efi_embedded_fw_checked;
| ^~~
| saved_efi_embedded_fw_checked
Caused by commit
18efb2f9e897 ("test_firmware: Test platform fw loading on non-EFI systems")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpt4WlwUKydW.pgp
Description: OpenPGP digital signature
Re: kernel BUG at /usr/src/kernel/lib/dynamic_debug.c:267!
Hi Naresh, Thanks for reporting, it seems that you have run the kselftests/livepatch/test-livepatch.sh. Then, I think it is better to report to Livepatch maintainers too. (I Cc'd them) Thank you, On Wed, 9 Sep 2020 10:24:09 +0530 Naresh Kamboju wrote: > While testing livepatch test cases on x86_64 with Linux next 20200908 tag > kernel > this kernel BUG noticed several times. > > metadata: > git branch: master > git repo: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > git commit: dff9f829e5b0181d4ed9d35aa62d695292399b54 > git describe: next-20200908 > kernel-config: > http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-next/853/config > > kernel BUG log, > -- > [ 634.063970] % rmmod test_klp_livepatch > [ 634.114787] test_klp_atomic_replace: this has been live patched > [ 634.121953] % echo 0 > > /sys/kernel/livepatch/test_klp_atomic_replace/enabled > [ 634.129391] livepatch: 'test_klp_atomic_replace': starting > unpatching transition > [ 634.143990] livepatch: 'test_klp_atomic_replace': unpatching complete > [ 634.156223] % rmmod test_klp_atomic_replace > [ 634.235451] [ cut here ] > [ 634.240314] kernel BUG at /usr/src/kernel/lib/dynamic_debug.c:267! > [ 634.246584] invalid opcode: [#1] SMP PTI > [ 634.250955] CPU: 0 PID: 12791 Comm: test-livepatch. Tainted: G > W K 5.9.0-rc4-next-20200908 #1 > [ 634.260615] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS > 2.2 05/23/2018 > [ 634.268007] RIP: 0010:ddebug_exec_query+0x77b/0xb90 > [ 634.272886] Code: 4c 89 ad 70 ff ff ff e9 db fb ff ff b8 03 00 00 > 00 e9 20 fb ff ff b8 02 00 00 00 e9 16 fb ff ff b8 01 00 00 00 e9 0c > fb ff ff <0f> 0b 31 c0 e9 03 fb ff ff 49 89 f4 48 89 f7 e9 78 f9 ff ff > 8b 15 > [ 634.291630] RSP: 0018:9f0c80a5bd18 EFLAGS: 00010246 > [ 634.296856] RAX: 003d RBX: RCX: > > [ 634.303987] RDX: 003d RSI: RDI: > 90db906583ec > [ 634.31] RBP: 9f0c80a5bde8 R08: 000a R09: > 003b > [ 634.318236] R10: 90db9261 R11: 0246 R12: > 90db906583ec > [ 634.325368] R13: be87cbc0 R14: R15: > 0004 > [ 634.332500] FS: 7fd37249a740() GS:90dbefa0() > knlGS: > [ 634.340578] CS: 0010 DS: ES: CR0: 80050033 > [ 634.346315] CR2: 00e6d00c CR3: 00026a4b8004 CR4: > 003706f0 > [ 634.353446] DR0: DR1: DR2: > > [ 634.360570] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 634.367693] Call Trace: > [ 634.370139] ? lock_acquire+0xa6/0x390 > [ 634.373892] ? __might_fault+0x34/0x80 > [ 634.377648] ddebug_exec_queries+0x6e/0x140 > [ 634.381831] ddebug_proc_write+0x4b/0xa0 > [ 634.385756] full_proxy_write+0x5f/0x90 > [ 634.389595] vfs_write+0xed/0x240 > [ 634.392915] ksys_write+0xad/0xf0 > [ 634.396233] ? syscall_trace_enter+0x17a/0x240 > [ 634.400670] __x64_sys_write+0x1a/0x20 > [ 634.404416] do_syscall_64+0x37/0x50 > [ 634.407993] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 634.413038] RIP: 0033:0x7fd371b84144 > [ 634.416617] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 > 00 00 00 00 66 90 48 8d 05 c1 e7 2c 00 8b 00 85 c0 75 13 b8 01 00 00 > 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 > f5 53 > [ 634.435362] RSP: 002b:7ffd19447658 EFLAGS: 0246 ORIG_RAX: > 0001 > [ 634.442928] RAX: ffda RBX: 00bc RCX: > 7fd371b84144 > [ 634.450059] RDX: 00bc RSI: 00e6cf70 RDI: > 0001 > [ 634.457181] RBP: 00e6cf70 R08: 00e9 R09: > > [ 634.464305] R10: 7ffd19447c48 R11: 0246 R12: > 7fd371e4e760 > [ 634.471429] R13: 00bc R14: 7fd371e49760 R15: > 00bc > [ 634.478559] Modules linked in: trace_printk sch_fq 8021q > iptable_filter xt_mark ip_tables cls_bpf sch_ingress veth algif_hash > x86_pkg_temp_thermal fuse [last unloaded: test_klp_atomic_replace] > [ 634.495695] ---[ end trace d04d7e11bd1458bf ]--- > [ 634.500333] RIP: 0010:ddebug_exec_query+0x77b/0xb90 > [ 634.505218] Code: 4c 89 ad 70 ff ff ff e9 db fb ff ff b8 03 00 00 > 00 e9 20 fb ff ff b8 02 00 00 00 e9 16 fb ff ff b8 01 00 00 00 e9 0c > fb ff ff <0f> 0b 31 c0 e9 03 fb ff ff 49 89 f4 48 89 f7 e9 78 f9 ff ff > 8b 15 > [ 634.523969] RSP: 0018:9f0c80a5bd18 EFLAGS: 00010246 > [ 634.529197] RAX: 003
[PATCH V4] arm64/cpuinfo: Define HWCAP name arrays per their actual bit definitions
HWCAP name arrays (hwcap_str, compat_hwcap_str, compat_hwcap2_str) that are
scanned for /proc/cpuinfo are detached from their bit definitions making it
vulnerable and difficult to correlate. It is also bit problematic because
during /proc/cpuinfo dump these arrays get traversed sequentially assuming
they reflect and match actual HWCAP bit sequence, to test various features
for a given CPU. This redefines name arrays per their HWCAP bit definitions
. It also warns after detecting any feature which is not expected on arm64.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Brown
Cc: Dave Martin
Cc: Ard Biesheuvel
Cc: Mark Rutland
Cc: Suzuki K Poulose
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
This applies on 5.9-rc4
Mark, since the patch has changed I have dropped your Acked-by: tag. Are you
happy to give a new one ?
Changes in V4:
- Unified all three HWCAP array traversal per Will
Changes in V3: (https://patchwork.kernel.org/patch/11718113/)
- Moved name arrays to (arch/arm64/kernel/cpuinfo.c) to prevent a build warning
- Replaced string values with NULL for all compat features not possible on arm64
- Changed compat_hwcap_str[] iteration on size as some NULL values are expected
- Warn once after detecting any feature on arm64 that is not expected
Changes in V2: (https://patchwork.kernel.org/patch/11533755/)
- Defined COMPAT_KERNEL_HWCAP[2] and updated the name arrays per Mark
- Updated the commit message as required
Changes in V1: (https://patchwork.kernel.org/patch/11532945/)
arch/arm64/include/asm/hwcap.h | 9 ++
arch/arm64/kernel/cpuinfo.c| 176 +
2 files changed, 101 insertions(+), 84 deletions(-)
diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
index 22f73fe09030..6493a4c63a2f 100644
--- a/arch/arm64/include/asm/hwcap.h
+++ b/arch/arm64/include/asm/hwcap.h
@@ -8,18 +8,27 @@
#include
#include
+#define COMPAT_HWCAP_SWP (1 << 0)
#define COMPAT_HWCAP_HALF (1 << 1)
#define COMPAT_HWCAP_THUMB (1 << 2)
+#define COMPAT_HWCAP_26BIT (1 << 3)
#define COMPAT_HWCAP_FAST_MULT (1 << 4)
+#define COMPAT_HWCAP_FPA (1 << 5)
#define COMPAT_HWCAP_VFP (1 << 6)
#define COMPAT_HWCAP_EDSP (1 << 7)
+#define COMPAT_HWCAP_JAVA (1 << 8)
+#define COMPAT_HWCAP_IWMMXT(1 << 9)
+#define COMPAT_HWCAP_CRUNCH(1 << 10)
+#define COMPAT_HWCAP_THUMBEE (1 << 11)
#define COMPAT_HWCAP_NEON (1 << 12)
#define COMPAT_HWCAP_VFPv3 (1 << 13)
+#define COMPAT_HWCAP_VFPV3D16 (1 << 14)
#define COMPAT_HWCAP_TLS (1 << 15)
#define COMPAT_HWCAP_VFPv4 (1 << 16)
#define COMPAT_HWCAP_IDIVA (1 << 17)
#define COMPAT_HWCAP_IDIVT (1 << 18)
#define COMPAT_HWCAP_IDIV (COMPAT_HWCAP_IDIVA|COMPAT_HWCAP_IDIVT)
+#define COMPAT_HWCAP_VFPD32(1 << 19)
#define COMPAT_HWCAP_LPAE (1 << 20)
#define COMPAT_HWCAP_EVTSTRM (1 << 21)
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index d0076c2159e6..04640f5f9f0f 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -43,94 +43,93 @@ static const char *icache_policy_str[] = {
unsigned long __icache_flags;
static const char *const hwcap_str[] = {
- "fp",
- "asimd",
- "evtstrm",
- "aes",
- "pmull",
- "sha1",
- "sha2",
- "crc32",
- "atomics",
- "fphp",
- "asimdhp",
- "cpuid",
- "asimdrdm",
- "jscvt",
- "fcma",
- "lrcpc",
- "dcpop",
- "sha3",
- "sm3",
- "sm4",
- "asimddp",
- "sha512",
- "sve",
- "asimdfhm",
- "dit",
- "uscat",
- "ilrcpc",
- "flagm",
- "ssbs",
- "sb",
- "paca",
- "pacg",
- "dcpodp",
- "sve2",
- "sveaes",
- "svepmull",
- "svebitperm",
- "svesha3",
- "svesm4",
- "flagm2",
- "frint",
- "svei8mm",
- "svef32mm",
- "svef64mm",
- "svebf16",
- "i8mm",
- "bf16",
- "dgh",
- "rng",
- "bti",
+ [KERNEL_HWCAP_FP] = "fp",
+ [KERNEL_HWCAP_ASIMD]= "asimd",
+ [KERNEL_HWCAP_EVTSTRM] = "evtstrm",
+ [KERNEL_HWCAP_AES] = "aes",
+ [KERNEL_HWCAP_PMULL]= "pmull",
+ [KERNEL_HWCAP_SHA1] = "sha1",
+ [KERNEL_HWCAP_SHA2] = "sha2",
+ [KERNEL_HWCAP_CRC32]= "crc32",
+ [KERNEL_HWCAP_ATOMICS] = "atomics",
+ [KERNEL_HWCAP_FPHP] = "fphp",
+ [KERNEL_HWCAP_ASIMDHP] = "asimdhp",
+ [KERNEL_HWCAP_CPUID]= "cpuid",
+ [KERNEL_HWCAP_ASIMDRDM] = "asimdrdm",
+ [KERNEL_HWCAP_JSCVT]= "jscvt",
+ [KERNEL_HWCAP_FCMA] = "fcma",
+ [KERNEL_HWCAP_LRCPC]= "lrcpc",
+ [KERNEL_HWCAP_DCPOP]
Re: [PATCH 5.8 000/186] 5.8.8-rc1 review
On Tue, 8 Sep 2020 at 21:05, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.8.8 release. > There are 186 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu, 10 Sep 2020 15:21:57 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.8-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.8.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.8.8-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.8.y git commit: 456fe9607f8f8a55179d2527598b8e90a2591e4d git describe: v5.8.7-187-g456fe9607f8f Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.8-oe/build/v5.8.7-187-g456fe9607f8f No regressions (compared to build v5.8.7) No fixes (compared to build v5.8.7) Ran 36239 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * build * igt-gpu-tools * install-android-platform-tools-r2600 * kselftest * kselftest/drivers * kselftest/filesystems * kselftest/net * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * v4l2-compliance * ltp-containers-tests * ltp-ipc-tests * ltp-tracing-tests * network-basic-tests * ltp-dio-tests * ltp-io-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-native/net * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems * kselftest-vsyscall-mode-none/net * ssuite -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 5.4 000/129] 5.4.64-rc1 review
On Tue, 8 Sep 2020 at 21:12, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.4.64 release. > There are 129 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu, 10 Sep 2020 15:21:57 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.64-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.4.64-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.4.y git commit: be965cc6b079fbac3bf73ce195ae06aa5314fd99 git describe: v5.4.63-130-gbe965cc6b079 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.63-130-gbe965cc6b079 No regressions (compared to build v5.4.63) No fixes (compared to build v5.4.63) Ran 34523 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * build * igt-gpu-tools * install-android-platform-tools-r2600 * kselftest * kselftest/drivers * kselftest/filesystems * kselftest/net * kvm-unit-tests * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-tracing-tests * perf * v4l2-compliance * ltp-commands-tests * ltp-ipc-tests * ltp-math-tests * ltp-syscalls-tests * network-basic-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-native/net * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems * kselftest-vsyscall-mode-none/net * ssuite -- Linaro LKFT https://lkft.linaro.org
Re: [RFC PATCH v2 0/6] SCHED_DEADLINE server infrastructure
Hi Pavel, On 09/09/20 00:22, Pavel Machek wrote: > Hi! > > > This is RFC v2 of Peter's SCHED_DEADLINE server infrastructure > > implementation [1]. > > > > SCHED_DEADLINE servers can help fixing starvation issues of low priority > > tasks (e.g., > > SCHED_OTHER) when higher priority tasks monopolize CPU cycles. Today we > > have RT > > Throttling; DEADLINE servers should be able to replace and improve that. > > It would be worth noting what "server" is in this context. It comes from Constant Bandwidth Server (CBS), that SCHED_DEADLINE is implementing [1]. > > It is not white box with CPU inside, it is not even an userland process, > afaict. > > Subject is quite confusing. Best, Juri 1 - https://elixir.bootlin.com/linux/latest/source/Documentation/scheduler/sched-deadline.rst#L42
Re: [PATCH] Rescan the entire target on transport reset when LUN is 0
On Tue, Sep 08, 2020 at 05:53:16PM +, Felipe Franciosi wrote:
>
>
> > On Sep 8, 2020, at 3:22 PM, Paolo Bonzini wrote:
> >
> > On 28/08/20 14:21, Matej Genci wrote:
> >> VirtIO 1.0 spec says
> >>The removed and rescan events ... when sent for LUN 0, they MAY
> >>apply to the entire target so the driver can ask the initiator
> >>to rescan the target to detect this.
> >>
> >> This change introduces the behaviour described above by scanning the
> >> entire scsi target when LUN is set to 0. This is both a functional and a
> >> performance fix. It aligns the driver with the spec and allows control
> >> planes to hotplug targets with large numbers of LUNs without having to
> >> request a RESCAN for each one of them.
> >>
> >> Signed-off-by: Matej Genci
> >> Suggested-by: Felipe Franciosi
> >> ---
> >> drivers/scsi/virtio_scsi.c | 7 ++-
> >> 1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
> >> index bfec84aacd90..a4b9bc7b4b4a 100644
> >> --- a/drivers/scsi/virtio_scsi.c
> >> +++ b/drivers/scsi/virtio_scsi.c
> >> @@ -284,7 +284,12 @@ static void virtscsi_handle_transport_reset(struct
> >> virtio_scsi *vscsi,
> >>
> >>switch (virtio32_to_cpu(vscsi->vdev, event->reason)) {
> >>case VIRTIO_SCSI_EVT_RESET_RESCAN:
> >> - scsi_add_device(shost, 0, target, lun);
> >> + if (lun == 0) {
> >> + scsi_scan_target(>shost_gendev, 0, target,
> >> + SCAN_WILD_CARD, SCSI_SCAN_INITIAL);
> >> + } else {
> >> + scsi_add_device(shost, 0, target, lun);
> >> + }
> >>break;
> >>case VIRTIO_SCSI_EVT_RESET_REMOVED:
> >>sdev = scsi_device_lookup(shost, 0, target, lun);
> >>
> >
> >
> > Acked-by: Paolo Bonzini
>
> Cc: sta...@vger.kernel.org
>
> Thanks, Paolo.
>
> I'm Cc'ing stable as I believe this fixes a driver bug where it
> doesn't follow the spec. Per commit message, today devices are
> required to issue RESCAN events for each LUN behind a target when
> hotplugging, or risking the driver not seeing the new LUNs.
>
> Is this enough? Or should we resend after merge per below?
> https://www.kernel.org/doc/Documentation/process/stable-kernel-rules.rst
You need to let stable know the git commit id of the patch in Linus's
tree if the cc: stable is not on the final commit that gets merged.
thanks,
greg k-h
linux-next: build warning after merge of the tty tree
Hi all,
After merging the tty tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/tty/serial/8250/8250_bcm2835aux.c: In function
'bcm2835aux_serial_probe':
drivers/tty/serial/8250/8250_bcm2835aux.c:154:3: warning: ignoring return value
of 'dev_err_probe' declared with attribute 'warn_unused_result'
[-Wunused-result]
154 | dev_err_probe(>dev, ret, "unable to register 8250 port\n");
| ^~~~
Introduced by commit
ea43a60b1548 ("serial: 8250: Simplify with dev_err_probe()")
--
Cheers,
Stephen Rothwell
pgp5MOzggYyyG.pgp
Description: OpenPGP digital signature
Re: Mailing list about low levels of Linux on cellphones
* Bhaskar Chowdhury [200908 23:08]: > On 00:56 Wed 09 Sep 2020, Pavel Machek wrote: > > Would it be possible to create a mailing list on vger.kernel.org? > > Probably phones@ or phone-devel@? I believe it would be useful to > > cover hardware-dependend pieces of the phone stack (ofono, > > modemmanager) as well as kernel. Good idea, probably phone-devel list would be better for Linux kernel stuff. Regards, Tony
[PATCH 2/3] perf list: Do not print 'Metric Groups:' unnecessarily
It was printed unconditionally even if nothing is printed.
Check if the output list empty when filter is given.
Before:
$ ./perf list duration
List of pre-defined events (to be used in -e):
duration_time [Tool event]
Metric Groups:
After:
$ ./perf list duration
List of pre-defined events (to be used in -e):
duration_time [Tool event]
Signed-off-by: Namhyung Kim
diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index 8831b964288f..38464d7d2d63 100644
--- a/tools/perf/util/metricgroup.c
+++ b/tools/perf/util/metricgroup.c
@@ -535,10 +535,12 @@ void metricgroup__print(bool metrics, bool metricgroups,
char *filter,
}
}
- if (metricgroups && !raw)
- printf("\nMetric Groups:\n\n");
- else if (metrics && !raw)
- printf("\nMetrics:\n\n");
+ if (!filter || !rblist__empty()) {
+ if (metricgroups && !raw)
+ printf("\nMetric Groups:\n\n");
+ else if (metrics && !raw)
+ printf("\nMetrics:\n\n");
+ }
for (node = rb_first_cached(); node; node = next) {
struct mep *me = container_of(node, struct mep, nd);
--
2.28.0.526.ge36021eeef-goog
[PATCH 3/3] perf list: Add 'pfm' to list libpfm4 events
Print libpfm4 events with 'perf list pfm' command like others.
When libpfm4 support is not enabled, it'd print nothing.
Also it support glob pattern matching for event name.
$ perf list pfm
List of pre-defined events (to be used in --pfm-events):
ix86arch:
UNHALTED_CORE_CYCLES
[count core clock cycles whenever the clock signal ...
INSTRUCTION_RETIRED
[count the number of instructions at retirement. ...
...
Signed-off-by: Namhyung Kim
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 10ab5e40a34f..167868053fe0 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -14,6 +14,7 @@
#include "util/pmu.h"
#include "util/debug.h"
#include "util/metricgroup.h"
+#include "util/pfm.h"
#include
#include
#include
@@ -42,7 +43,7 @@ int cmd_list(int argc, const char **argv)
OPT_END()
};
const char * const list_usage[] = {
- "perf list []
[hw|sw|cache|tracepoint|pmu|sdt|metric|metricgroup|event_glob]",
+ "perf list []
[hw|sw|cache|tracepoint|pmu|sdt|metric|metricgroup|pfm|event_glob]",
NULL
};
@@ -53,7 +54,7 @@ int cmd_list(int argc, const char **argv)
setup_pager();
- if (!raw_dump && pager_in_use())
+ if (!raw_dump && pager_in_use() && (argc != 1 || strcmp(argv[0],
"pfm")))
printf("\nList of pre-defined events (to be used in -e):\n\n");
if (argc == 0) {
@@ -89,6 +90,8 @@ int cmd_list(int argc, const char **argv)
metricgroup__print(true, false, NULL, raw_dump,
details_flag);
else if (strcmp(argv[i], "metricgroup") == 0 || strcmp(argv[i],
"metricgroups") == 0)
metricgroup__print(false, true, NULL, raw_dump,
details_flag);
+ else if (strcmp(argv[i], "pfm") == 0)
+ print_libpfm_events(NULL, raw_dump, long_desc_flag);
else if ((sep = strchr(argv[i], ':')) != NULL) {
int sep_idx;
@@ -120,6 +123,7 @@ int cmd_list(int argc, const char **argv)
print_tracepoint_events(NULL, s, raw_dump);
print_sdt_events(NULL, s, raw_dump);
metricgroup__print(true, true, s, raw_dump,
details_flag);
+ print_libpfm_events(s, raw_dump, long_desc_flag);
free(s);
}
}
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 772f1057647f..ae8ab930a792 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -2593,7 +2593,7 @@ static struct option __record_options[] = {
"number of threads to run for event synthesis"),
#ifdef HAVE_LIBPFM
OPT_CALLBACK(0, "pfm-events", , "event",
- "libpfm4 event selector. use 'perf list' to list available
events",
+ "libpfm4 event selector. use 'perf list pfm' to list available
events",
parse_libpfm_events_option),
#endif
OPT_CALLBACK(0, "control", , "fd:ctl-fd[,ack-fd]",
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 483a28ef4ec4..a672d2b68e8a 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1166,7 +1166,7 @@ static struct option stat_options[] = {
"threads of same physical core"),
#ifdef HAVE_LIBPFM
OPT_CALLBACK(0, "pfm-events", _list, "event",
- "libpfm4 event selector. use 'perf list' to list available
events",
+ "libpfm4 event selector. use 'perf list pfm' to list available
events",
parse_libpfm_events_option),
#endif
OPT_CALLBACK(0, "control", _config, "fd:ctl-fd[,ack-fd]",
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 7c64134472c7..d6adc7d34210 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1578,7 +1578,7 @@ int cmd_top(int argc, const char **argv)
"Enable LBR callgraph stitching approach"),
#ifdef HAVE_LIBPFM
OPT_CALLBACK(0, "pfm-events", , "event",
- "libpfm4 event selector. use 'perf list' to list available
events",
+ "libpfm4 event selector. use 'perf list pfm' to list available
events",
parse_libpfm_events_option),
#endif
OPTS_EVSWITCH(),
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index c4d2394e2b2d..2d426a4f3bc7 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -2899,7 +2899,7 @@ void print_events(const char *event_glob, bool name_only,
bool quiet_flag,
metricgroup__print(true, true, NULL, name_only, details_flag);
- print_libpfm_events(name_only, long_desc);
+ print_libpfm_events(NULL, name_only, long_desc);
}
int parse_events__is_hardcoded_term(struct parse_events_term *term)
diff --git a/tools/perf/util/pfm.c
[PATCH 1/3] perf list: Remove dead code in argument check
The sep is already checked being not NULL. The code seems to be a
leftover from some refactoring.
Signed-off-by: Namhyung Kim
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 0a7fe4cb..10ab5e40a34f 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -92,13 +92,6 @@ int cmd_list(int argc, const char **argv)
else if ((sep = strchr(argv[i], ':')) != NULL) {
int sep_idx;
- if (sep == NULL) {
- print_events(argv[i], raw_dump, !desc_flag,
- long_desc_flag,
- details_flag,
- deprecated);
- continue;
- }
sep_idx = sep - argv[i];
s = strdup(argv[i]);
if (s == NULL)
--
2.28.0.526.ge36021eeef-goog
Re: [PATCH v2 10/11] dwc3-of-simple: add support for Hikey 970
Hi, Mauro Carvalho Chehab writes: > This binding driver is needed for Hikey 970 to work, > as otherwise a Serror is produced: > > [1.837458] SError Interrupt on CPU0, code 0xbf02 -- SError > [1.837462] CPU: 0 PID: 74 Comm: kworker/0:1 Not tainted 5.8.0+ #205 > [1.837463] Hardware name: HiKey970 (DT) > [1.837465] Workqueue: events deferred_probe_work_func > [1.837467] pstate: 2005 (nzCv daif -PAN -UAO BTYPE=--) > [1.837468] pc : _raw_spin_unlock_irqrestore+0x18/0x50 > [1.837469] lr : regmap_unlock_spinlock+0x14/0x20 > [1.837470] sp : 8000124dba60 > [1.837471] x29: 8000124dba60 x28: > [1.837474] x27: 0001b7e854c8 x26: 80001204ea18 > [1.837476] x25: 0005 x24: 800011f918f8 > [1.837479] x23: 800011fbb588 x22: 0001b7e40e00 > [1.837481] x21: 0100 x20: > [1.837483] x19: 0001b767ec00 x18: ff10c000 > [1.837485] x17: 0002 x16: b0740fdb9950 > [1.837488] x15: 8000116c1198 x14: > [1.837490] x13: 0030 x12: 0101010101010101 > [1.837493] x11: 0020 x10: 0001bf17d130 > [1.837495] x9 : x8 : 0001b6938080 > [1.837497] x7 : x6 : 003f > [1.837500] x5 : x4 : > [1.837502] x3 : 80001096a880 x2 : > [1.837505] x1 : 0001b7e40e00 x0 : 00010001 > [1.837507] Kernel panic - not syncing: Asynchronous SError Interrupt > [1.837509] CPU: 0 PID: 74 Comm: kworker/0:1 Not tainted 5.8.0+ #205 > [1.837510] Hardware name: HiKey970 (DT) > [1.837511] Workqueue: events deferred_probe_work_func > [1.837513] Call trace: > [1.837514] dump_backtrace+0x0/0x1e0 > [1.837515] show_stack+0x18/0x24 > [1.837516] dump_stack+0xc0/0x11c > [1.837517] panic+0x15c/0x324 > [1.837518] nmi_panic+0x8c/0x90 > [1.837519] arm64_serror_panic+0x78/0x84 > [1.837520] do_serror+0x158/0x15c > [1.837521] el1_error+0x84/0x100 > [1.837522] _raw_spin_unlock_irqrestore+0x18/0x50 > [1.837523] regmap_write+0x58/0x80 > [1.837524] hi3660_reset_deassert+0x28/0x34 > [1.837526] reset_control_deassert+0x50/0x260 > [1.837527] reset_control_deassert+0xf4/0x260 > [1.837528] dwc3_probe+0x5dc/0xe6c > [1.837529] platform_drv_probe+0x54/0xb0 > [1.837530] really_probe+0xe0/0x490 > [1.837531] driver_probe_device+0xf4/0x160 > [1.837532] __device_attach_driver+0x8c/0x114 > [1.837533] bus_for_each_drv+0x78/0xcc > [1.837534] __device_attach+0x108/0x1a0 > [1.837535] device_initial_probe+0x14/0x20 > [1.837537] bus_probe_device+0x98/0xa0 > [1.837538] deferred_probe_work_func+0x88/0xe0 > [1.837539] process_one_work+0x1cc/0x350 > [1.837540] worker_thread+0x2c0/0x470 > [1.837541] kthread+0x154/0x160 > [1.837542] ret_from_fork+0x10/0x30 > [1.837569] SMP: stopping secondary CPUs > [1.837570] Kernel Offset: 0x1d from 0x80001000 > [1.837571] PHYS_OFFSET: 0x0 > [1.837572] CPU features: 0x240002,20882004 > [1.837573] Memory Limit: none > > Signed-off-by: Mauro Carvalho Chehab applied for v5.9-rc -- balbi signature.asc Description: PGP signature
[PATCH v1] spi: spi-nxp-fspi: Add ACPI support
Currently NXP fspi driver has support of DT only. Adding ACPI
support to the driver so that it can be used by UEFI firmware
booting in ACPI mode. This driver will be probed if any firmware
will expose HID "NXP0009" in DSDT table.
Signed-off-by: kuldip dwivedi
---
Notes:
1. Add ACPI match table
2. Change the DT specific APIs to device property APIs
so that same API can be used in DT and ACPi mode.
3. Omit clock configuration part - in ACPI world, the firmware
is responsible for clock maintenance.
4. This patch is tested on LX2160A platform
drivers/spi/spi-nxp-fspi.c | 66 +++---
1 file changed, 47 insertions(+), 19 deletions(-)
diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c
index 1ccda82da206..acdb186ddfb2 100644
--- a/drivers/spi/spi-nxp-fspi.c
+++ b/drivers/spi/spi-nxp-fspi.c
@@ -3,7 +3,8 @@
/*
* NXP FlexSPI(FSPI) controller driver.
*
- * Copyright 2019 NXP.
+ * Copyright 2019-2020 NXP
+ * Copyright 2020 Puresoftware Ltd.
*
* FlexSPI is a flexsible SPI host controller which supports two SPI
* channels and up to 4 external devices. Each channel supports
@@ -30,6 +31,7 @@
* Frieder Schrempf
*/
+#include
#include
#include
#include
@@ -563,6 +565,9 @@ static int nxp_fspi_clk_prep_enable(struct nxp_fspi *f)
{
int ret;
+ if (is_acpi_node(f->dev->fwnode))
+ return 0;
+
ret = clk_prepare_enable(f->clk_en);
if (ret)
return ret;
@@ -576,10 +581,15 @@ static int nxp_fspi_clk_prep_enable(struct nxp_fspi *f)
return 0;
}
-static void nxp_fspi_clk_disable_unprep(struct nxp_fspi *f)
+static int nxp_fspi_clk_disable_unprep(struct nxp_fspi *f)
{
+ if (is_acpi_node(f->dev->fwnode))
+ return 0;
+
clk_disable_unprepare(f->clk);
clk_disable_unprepare(f->clk_en);
+
+ return 0;
}
/*
@@ -900,6 +910,8 @@ static int nxp_fspi_default_setup(struct nxp_fspi *f)
return ret;
/* Reset the module */
+ fspi_writel(f, FSPI_MCR0_SWRST, (base + FSPI_MCR0));
+
/* w1c register, wait unit clear */
ret = fspi_readl_poll_tout(f, f->iobase + FSPI_MCR0,
FSPI_MCR0_SWRST, 0, POLL_TOUT, false);
@@ -1001,7 +1013,7 @@ static int nxp_fspi_probe(struct platform_device *pdev)
f = spi_controller_get_devdata(ctlr);
f->dev = dev;
- f->devtype_data = of_device_get_match_data(dev);
+ f->devtype_data = device_get_match_data(dev);
if (!f->devtype_data) {
ret = -ENODEV;
goto err_put_ctrl;
@@ -1011,6 +1023,8 @@ static int nxp_fspi_probe(struct platform_device *pdev)
/* find the resources - configuration register address space */
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "fspi_base");
+ if (!res)
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
f->iobase = devm_ioremap_resource(dev, res);
if (IS_ERR(f->iobase)) {
ret = PTR_ERR(f->iobase);
@@ -1020,8 +1034,11 @@ static int nxp_fspi_probe(struct platform_device *pdev)
/* find the resources - controller memory mapped space */
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "fspi_mmap");
if (!res) {
- ret = -ENODEV;
- goto err_put_ctrl;
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!res) {
+ ret = -ENODEV;
+ goto err_put_ctrl;
+ }
}
/* assign memory mapped starting address and mapped size. */
@@ -1029,22 +1046,24 @@ static int nxp_fspi_probe(struct platform_device *pdev)
f->memmap_phy_size = resource_size(res);
/* find the clocks */
- f->clk_en = devm_clk_get(dev, "fspi_en");
- if (IS_ERR(f->clk_en)) {
- ret = PTR_ERR(f->clk_en);
- goto err_put_ctrl;
- }
+ if (dev_of_node(>dev)) {
+ f->clk_en = devm_clk_get(dev, "fspi_en");
+ if (IS_ERR(f->clk_en)) {
+ ret = PTR_ERR(f->clk_en);
+ goto err_put_ctrl;
+ }
- f->clk = devm_clk_get(dev, "fspi");
- if (IS_ERR(f->clk)) {
- ret = PTR_ERR(f->clk);
- goto err_put_ctrl;
- }
+ f->clk = devm_clk_get(dev, "fspi");
+ if (IS_ERR(f->clk)) {
+ ret = PTR_ERR(f->clk);
+ goto err_put_ctrl;
+ }
- ret = nxp_fspi_clk_prep_enable(f);
- if (ret) {
- dev_err(dev, "can not enable the clock\n");
- goto err_put_ctrl;
+ ret = nxp_fspi_clk_prep_enable(f);
+ if (ret) {
+ dev_err(dev, "can not enable the clock\n");
+ goto err_put_ctrl;
+ }
Re: [PATCH v6 04/13] usb: dwc3: Add splitdisable quirk for Hisilicon Kirin Soc
Hi,
Mauro Carvalho Chehab writes:
>> > I tested here, together with the Hikey 970 phy RFC patches I sent
>> > last week.
>> >
>> > Without this patch, the USB HID driver receives -EPROTO from
>> > submitted URBs, causing it to enter into an endless reset cycle
>> > on every 500 ms, at the hid_io_error() logic.
>>
>> > Tested-by: Mauro Carvalho Chehab
>> >
>> > If you prefer, I can re-submit this one with my SOB.
>>
>> Please do, but since you're changing device tree, I need Rob's acked-by.
>
> Ok, I'll do that.
thanks
>> > Em Sat, 20 Apr 2019 14:40:10 +0800
>> > Yu Chen escreveu:
>> >
>> >> SPLIT_BOUNDARY_DISABLE should be set for DesignWare USB3 DRD Core
>> >> of Hisilicon Kirin Soc when dwc3 core act as host.
>>
>> is this Kirin-specific or is this something that we should do a revision
>> check?
>
> I've no idea. I don't have any datasheets from this device.
I see
>> Why does it affect only Hikey kirin?
>
> As John Stultz didn't re-submit this one (and looking at the DT
> between Kirin 960 and 970 from the original Kernel 4.9 official
> drivers), I suspect that only Kirin 970 requires this quirk.
>
> It could well be due to some Dwc3 revision, but it could also be due
> to some differences at the USB part of the SoC, as there are a
the reason I ask is that if it's caused by dwc3 revision, then we don't
need the extra dt property, we can rely on a revision check. If it's
something that can't be detected in runtime, then we need a property.
> few other things different between hikey 960 and 970: it has a
> different PHY driver, and there are also some differences at the
> USB HUB which is connected into it.
>
> On both devices, the USB physical ports are actually connected
> into a HUB. In the case of Hikey 970, the hub seems to be a
> TI TUSB8041 4-Port Hub:
>
> $ lsusb
> Bus 002 Device 002: ID 0451:8140 Texas Instruments, Inc. TUSB8041
> 4-Port Hub
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 004: ID 090c:1000 Silicon Motion, Inc. - Taiwan
> (formerly Feiya Technology Corp.) Flash Drive
> Bus 001 Device 003: ID 413c:301a Dell Computer Corp. Dell MS116 Optical
> Mouse
> Bus 001 Device 002: ID 0451:8142 Texas Instruments, Inc. TUSB8041
> 4-Port Hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
>> What's the dwc3 revision on
>> that SoC (grep SNPSID /sys/kernel/debugfs/*dwc3/regdump)?
>
> GSNPSID = 0x33313130
This isn't even listed as a known revision in dwc3/core.h. Thinh, could
the issue being described here caused by a known Erratum with this
particular revision?
>> >> + reg = dwc3_readl(dwc->regs, DWC3_GUCTL3);
>> >> + reg |= DWC3_GUCTL3_SPLITDISABLE;
>> >> + dwc3_writel(dwc->regs, DWC3_GUCTL3, reg);
>> >> + }
>> >> +}
>> >> +#else
>> >> +#define dwc3_complete NULL
>> >> #endif /* CONFIG_PM_SLEEP */
>> >>
>> >> static const struct dev_pm_ops dwc3_dev_pm_ops = {
>> >> SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
>> >> + .complete = dwc3_complete,
>>
>> why is this done on complete? Why can't it be done at the end of
>> dwc3_resume()?
>
> Again, no idea. I didn't actually tried to suspend/resume.
>
> Maybe the original author can shed a light on it.
yeah, would be nice :-)
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH V2 5/5] DO NOT MERGE: iommu: disable list appending in dma-iommu
Hi Christoph, On 9/8/20 1:55 PM, Christoph Hellwig wrote: On Tue, Sep 08, 2020 at 06:36:19AM +0100, Christoph Hellwig wrote: On Mon, Sep 07, 2020 at 09:18:50PM +0100, Tom Murphy wrote: Yeah we talked about passing an attr to map_sg to disable merging at the following microconfernce: https://linuxplumbersconf.org/event/7/contributions/846/ As far as I can remember everyone seemed happy with that solution. I won't be working on this though as I don't have any more time to dedicate to this. It seems Lu Baolu will take over this. I'm absolutely again passing a flag. Tha just invites further abuse. We need a PCI ID based quirk or something else that can't be as easily abused. Also, I looked at i915 and there are just three dma_map_sg callers. The two dmabuf related ones are fixed by Marek in his series, leaving Do you mind telling where can I find Marek's series? Best regards, baolu just the one in i915_gem_gtt_prepare_pages, which does indeed look very fishy. But if that one is so hard to fix it can just be replaced by an open coded for_each_sg loop that contains manual dma_map_page calls. ___ iommu mailing list io...@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/3] dt-bindings: usb: Convert cdns-usb3.txt to YAML schema
Hi, Roger Quadros writes: > Converts cdns-usb3.txt to YAML schema cdns,usb3.yaml > > Signed-off-by: Roger Quadros > --- > .../devicetree/bindings/usb/cdns,usb3.yaml| 89 +++ > .../devicetree/bindings/usb/cdns-usb3.txt | 45 -- Rob, should I wait for your Ack on yaml conversions? -- balbi signature.asc Description: PGP signature
Re: [PATCH 1/9] mm/maccess: fix unaligned copy_{from,to}_kernel_nofault
Looks good: Reviewed-by: Christoph Hellwig This should probably go into Al's base.set_fs branch.
Aw: Re: [PATCH v4 0/4] Split PCIe node to comply with hardware design
Hi, i don't see this Patchset in 5.9-rc4 is anything missing? regards Frank
Re: [PATCH v3] dt-bindings: crypto: Specify that allwinner,sun8i-a33-crypto needs reset
On Mon, Sep 07, 2020 at 07:54:37PM +0200, Corentin Labbe wrote:
> When adding allwinner,sun8i-a33-crypto, I forgot to add that it needs reset.
> Furthermore, there are no need to use items to list only one compatible
> in compatible list.
>
> Fixes: f81547ba7a98 ("dt-bindings: crypto: add new compatible for A33 SS")
> Signed-off-by: Corentin Labbe
Acked-by: Maxime Ripard
Thanks!
Maxime
signature.asc
Description: PGP signature
Re: [PATCH 2/9] ARM: traps: use get_kernel_nofault instead of set_fs()
> +static void dump_mem(const char *, const char *, unsigned long, unsigned
> long, bool kernel_mode);
This adds a pointlessly long line.
And looking at the code I don't see why the argument is even needed.
dump_mem() currently does an unconditional set_fs(KERNEL_DS), so it
should always use get_kernel_nofault.
> +static void dump_instr(const char *lvl, struct pt_regs *regs)
> {
> unsigned long addr = instruction_pointer(regs);
> const int thumb = thumb_mode(regs);
> @@ -173,10 +169,20 @@ static void __dump_instr(const char *lvl, struct
> pt_regs *regs)
> for (i = -4; i < 1 + !!thumb; i++) {
> unsigned int val, bad;
>
> - if (thumb)
> - bad = get_user(val, &((u16 *)addr)[i]);
> - else
> - bad = get_user(val, &((u32 *)addr)[i]);
> + if (!user_mode(regs)) {
> + if (thumb) {
> + u16 val16;
> + bad = get_kernel_nofault(val16, &((u16
> *)addr)[i]);
> + val = val16;
> + } else {
> + bad = get_kernel_nofault(val, &((u32
> *)addr)[i]);
> + }
> + } else {
> + if (thumb)
> + bad = get_user(val, &((u16 *)addr)[i]);
> + else
> + bad = get_user(val, &((u32 *)addr)[i]);
> + }
When I looked at this earlier I just added a little helper to make
this a little easier to read. Here is my patch from an old tree:
http://git.infradead.org/users/hch/misc.git/commitdiff/67413030ccb7a64a7eb828e13ff0795f4eadfeb7
Re: [PATCH 3/9] ARM: oabi-compat: add epoll_pwait handler
> +SYSCALL_DEFINE4(oabi_epoll_wait, int, epfd, struct oabi_epoll_event __user > *, events, > + int, maxevents, int, timeout) > +SYSCALL_DEFINE6(oabi_epoll_pwait, int, epfd, struct oabi_epoll_event __user > *, events, > + int, maxevents, int, timeout, const sigset_t __user *, sigmask, > + size_t, sigsetsize) More pointlessly long lines.. Otherwise this looks good to me: Reviewed-by: Christoph Hellwig
Re: [PATCH v3 1/2] iio: adc: mt6360: Add ADC driver for MT6360
Jonathan Cameron 於 2020年8月30日 週日 上午1:12寫道：
>
> On Mon, 24 Aug 2020 17:06:24 +0800
> Gene Chen wrote:
>
> > From: Gene Chen
> >
> > Add MT6360 ADC driver include Charger Current, Voltage, and
> > Temperature.
> >
> > Signed-off-by: Gene Chen
> Hi Gene,
>
> A few comments inline. The big one centres on why we can't
> expose the channels as _raw, _offset and _scale?
>
I think i have 3 reason for use real value,
ADC is used to get real value rather than raw data which is not meaningful.
And I can decide which formula needs apply according to different condition.
Also the junction temperature channel _scale is floating point 1.05
which is not easy to express.
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/iio/adc/Kconfig | 11 ++
> > drivers/iio/adc/Makefile | 1 +
> > drivers/iio/adc/mt6360-adc.c | 366
> > +++
> > 3 files changed, 378 insertions(+)
> > create mode 100644 drivers/iio/adc/mt6360-adc.c
> >
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 66d9cc0..07dcea7 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -703,6 +703,17 @@ config MCP3911
> > This driver can also be built as a module. If so, the module will be
> > called mcp3911.
> >
> > +config MEDIATEK_MT6360_ADC
> > + tristate "Mediatek MT6360 ADC Part"
> > + depends on MFD_MT6360
> > + select IIO_BUFFER
> > + select IIO_TRIGGERED_BUFFER
> > + help
> > + Say Y here to enable MT6360 ADC Part.
> > + Integrated for System Monitoring include
> > + Charger and Battery Current, Voltage and
> > + Temperature
> > +
> > config MEDIATEK_MT6577_AUXADC
> > tristate "MediaTek AUXADC driver"
> > depends on ARCH_MEDIATEK || COMPILE_TEST
> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > index 90f94ad..5fca90a 100644
> > --- a/drivers/iio/adc/Makefile
> > +++ b/drivers/iio/adc/Makefile
> > @@ -65,6 +65,7 @@ obj-$(CONFIG_MAX9611) += max9611.o
> > obj-$(CONFIG_MCP320X) += mcp320x.o
> > obj-$(CONFIG_MCP3422) += mcp3422.o
> > obj-$(CONFIG_MCP3911) += mcp3911.o
> > +obj-$(CONFIG_MEDIATEK_MT6360_ADC) += mt6360-adc.o
> > obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
> > obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
> > obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
> > diff --git a/drivers/iio/adc/mt6360-adc.c b/drivers/iio/adc/mt6360-adc.c
> > new file mode 100644
> > index 000..5eed812
> > --- /dev/null
> > +++ b/drivers/iio/adc/mt6360-adc.c
> > @@ -0,0 +1,366 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2020 MediaTek Inc.
> > + *
> > + * Author: Gene Chen
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define MT6360_REG_PMUCHGCTRL3 0x313
> > +#define MT6360_REG_PMUADCCFG 0x356
> > +#define MT6360_REG_PMUADCRPT10x35A
> > +
> > +/* PMUCHGCTRL3 0x313 */
> > +#define MT6360_AICR_MASK 0xFC
> > +#define MT6360_AICR_SHFT 2
> > +#define MT6360_AICR_400MA0x6
> > +/* PMUADCCFG 0x356 */
> > +#define MT6360_ADCEN_MASK0x8000
> > +/* PMUADCRPT1 0x35A */
> > +#define MT6360_PREFERCH_MASK 0xF0
> > +#define MT6360_PREFERCH_SHFT 4
> > +#define MT6360_RPTCH_MASK0x0F
> > +
> > +enum {
> > + MT6360_CHAN_USBID = 0,
> > + MT6360_CHAN_VBUSDIV5,
> > + MT6360_CHAN_VBUSDIV2,
> > + MT6360_CHAN_VSYS,
> > + MT6360_CHAN_VBAT,
> > + MT6360_CHAN_IBUS,
> > + MT6360_CHAN_IBAT,
> > + MT6360_CHAN_CHG_VDDP,
> > + MT6360_CHAN_TEMP_JC,
> > + MT6360_CHAN_VREF_TS,
> > + MT6360_CHAN_TS,
> > + MT6360_CHAN_MAX,
> > +};
> > +
> > +struct mt6360_adc_data {
> > + struct device *dev;
> > + struct regmap *regmap;
> > + struct completion adc_complete;
> > + struct mutex adc_lock;
> > + ktime_t last_off_timestamps[MT6360_CHAN_MAX];
> > + int irq;
> > +};
> > +
> > +static inline int mt6360_adc_val_converter(int val, int multiplier, int
> > offset, int divisor)
> > +{
> > + return ((val * multiplier) + offset) / divisor;
>
> Why could we not report these values to userspace or consumer drivers and let
> them deal with the conversion if they actually needed it?
> Mapping this to
>
> (val + new_offset) * multiplier would be a little messy, but not too bad.
>
> The advantage would be that we would then be providing the data needed
> to get real units for values read from the buffers without having to
> do all the maths in kernel (without access to floating point).
>
>
As above, if I use formula "(val + new_offset) * multiplier",
the junction temperature channel multiplier will be floating point
1.05, i don't know how to express.
> > +}
> > +
> > +static int mt6360_adc_convert_processed_val(struct mt6360_adc_data *info,
> > int chan_idx, int *val)
> > +{
> > + unsigned int
Re: [PATCH 5/9] ARM: oabi-compat: rework epoll_wait/epoll_pwait emulation
On Mon, Sep 07, 2020 at 05:36:46PM +0200, Arnd Bergmann wrote:
> The epoll_wait() system call wrapper is one of the remaining users of
> the set_fs() infrasturcture for Arm. Changing it to not require set_fs()
> is rather complex unfortunately.
>
> The approach I'm taking here is to allow architectures to override
> the code that copies the output to user space, and let the oabi-compat
> implementation check whether it is getting called from an EABI or OABI
> system call based on the thread_info->syscall value.
>
> The in_oabi_syscall() check here mirrors the in_compat_syscall() and
> in_x32_syscall() helpers for 32-bit compat implementations on other
> architectures.
>
> Overall, the amount of code goes down, at least with the newly added
> sys_oabi_epoll_pwait() helper getting removed again. The downside
> is added complexity in the source code for the native implementation.
> There should be no difference in runtime performance except for Arm
> kernels with CONFIG_OABI_COMPAT enabled that now have to go through
> an external function call to check which of the two variants to use.
>
> Signed-off-by: Arnd Bergmann
> ---
> arch/arm/include/asm/syscall.h| 11 +
> arch/arm/kernel/sys_oabi-compat.c | 72 +++
> arch/arm/tools/syscall.tbl| 4 +-
> fs/eventpoll.c| 5 +--
> include/linux/eventpoll.h | 16 +++
> 5 files changed, 46 insertions(+), 62 deletions(-)
>
> diff --git a/arch/arm/include/asm/syscall.h b/arch/arm/include/asm/syscall.h
> index ff6cc365eaf7..0d8afceeefd9 100644
> --- a/arch/arm/include/asm/syscall.h
> +++ b/arch/arm/include/asm/syscall.h
> @@ -28,6 +28,17 @@ static inline int syscall_get_nr(struct task_struct *task,
> return task_thread_info(task)->syscall;
> }
>
> +static inline bool __in_oabi_syscall(struct task_struct *task)
> +{
> + return IS_ENABLED(CONFIG_OABI_COMPAT) &&
> + (task_thread_info(task)->syscall & __NR_OABI_SYSCALL_BASE);
> +}
> +
> +static inline bool in_oabi_syscall(void)
> +{
> + return __in_oabi_syscall(current);
> +}
> +
> static inline void syscall_rollback(struct task_struct *task,
> struct pt_regs *regs)
> {
> diff --git a/arch/arm/kernel/sys_oabi-compat.c
> b/arch/arm/kernel/sys_oabi-compat.c
> index 2ce3e8c6ca91..abf1153c5315 100644
> --- a/arch/arm/kernel/sys_oabi-compat.c
> +++ b/arch/arm/kernel/sys_oabi-compat.c
> @@ -83,6 +83,8 @@
> #include
> #include
>
> +#include
> +
> struct oldabi_stat64 {
> unsigned long long st_dev;
> unsigned int__pad1;
> @@ -264,68 +266,24 @@ asmlinkage long sys_oabi_epoll_ctl(int epfd, int op,
> int fd,
> return do_epoll_ctl(epfd, op, fd, , false);
> }
>
> -static long do_oabi_epoll_wait(int epfd, struct oabi_epoll_event __user
> *events,
> -int maxevents, int timeout)
> +struct epoll_event __user *
> +epoll_put_uevent(__poll_t revents, __u64 data, struct epoll_event __user
> *uevent)
> {
> + if (in_oabi_syscall()) {
> + struct oabi_epoll_event *oevent = (void __user *)uevent;
>
> + if (__put_user(revents, >events) ||
> + __put_user(data, >data))
> + return NULL;
>
> + return (void __user *)uevent+1;
> + }
I wonder if we'd be better off doing the in_oabi_syscall() branch in
the common code. E.g. rename in_oabi_syscall to in_legacy_syscall and
stub it out for all other architectures. Then just do
if (in_oabi_syscall()
legacy_syscall_foo_bit();
else
normal_syscall_foo_bit();
in common code, where so far only arm provides
legacy_syscall_foo_bit().
Tons of long lines again in this patch..
Re: [PATCH v3] dt-bindings: crypto: Specify that allwinner,sun8i-a33-crypto needs reset
On Tue, Sep 08, 2020 at 08:15:56AM +0200, Maxime Ripard wrote:
> On Mon, Sep 07, 2020 at 07:54:37PM +0200, Corentin Labbe wrote:
> > When adding allwinner,sun8i-a33-crypto, I forgot to add that it needs reset.
> > Furthermore, there are no need to use items to list only one compatible
> > in compatible list.
> >
> > Fixes: f81547ba7a98 ("dt-bindings: crypto: add new compatible for A33 SS")
> > Signed-off-by: Corentin Labbe
>
> Acked-by: Maxime Ripard
Nevermind, I assumed that there would be crypto patches, but there's
none so I ended up taking it through our tree.
Maxime
signature.asc
Description: PGP signature
Re: linux-next: manual merge of the mmc tree with the samsung-krzk tree
On Tue, 8 Sep 2020 at 06:46, Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the mmc tree got a conflict in:
>
> drivers/mmc/host/Kconfig
>
> between commits:
>
> cb6c03019cdd ("ARM: exynos: stop selecting PLAT_SAMSUNG")
> db8230d29c3a ("ARM: s5pv210: don't imply CONFIG_PLAT_SAMSUNG")
>
> from the samsung-krzk tree and commit:
>
> 54d8454436a2 ("mmc: host: Enable compile testing of multiple drivers")
>
> from the mmc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/mmc/host/Kconfig
> index 0d7c61d8d1d9,dc646359b4ff..
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@@ -289,7 -301,8 +301,8 @@@ config MMC_SDHCI_TEGR
>
> config MMC_SDHCI_S3C
> tristate "SDHCI support on Samsung S3C SoC"
> - depends on MMC_SDHCI && (PLAT_SAMSUNG || ARCH_S5PV210 || ARCH_EXYNOS)
> + depends on MMC_SDHCI
> - depends on PLAT_SAMSUNG || COMPILE_TEST
> ++ depends on PLAT_SAMSUNG || ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
Thanks, this is the expected resolution.
Best regards,
Krzysztof
Re: [PATCH v3 0/2] ARM: dts: sun8i: v3s: Enable crypto engine
On Mon, Sep 07, 2020 at 06:24:56PM +0200, Martin Cerveny wrote: > Add support for crypto engine (sun4i-ss) for Allwinner V3s. > Functionality like A33 so add only compatible and enable > in device tree. > > Regards. Applied, thanks Maxime signature.asc Description: PGP signature
Re: [PATCH v1 6/8] x86/tsc: Use seqcount_latch_t
On Mon, Sep 07, 2020 at 07:30:47PM +0200, pet...@infradead.org wrote: ... > > Don't look at this function in isolation, look at native_sched_clock() > where it's used as a whole. > ... > What happened (afaict) is that the change caused it to use more > registers and ended up spiling crap on the stack. > ... > > Anyway, I frobbed the patch to use the this_cpu variant, and I've queued > the lot. Perfect. Thanks a lot ;-)
[git pull] drm fixes for 5.9-rc5 (special edition)
Hi Linus, The i915 reverts are going to be a bit of a conflict mess for next, so I decided to dequeue them now, along with some msm fixes for a ring corruption issue, that Rob sent over the weekend. Dave. drm-fixes-2020-09-08: drm fixes for 5.9-rc5 (special edition) i915: - revert gpu relocation changes due to regression msm: - fixes for RPTR corruption issue The following changes since commit f4d51dffc6c01a9e94650d95ce0104964f8ae822: Linux 5.9-rc4 (2020-09-06 17:11:40 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-09-08 for you to fetch changes up to 20561da3a2e1e0e827ef5510cb0f74bcfd377e41: Revert "drm/i915/gem: Delete unused code" (2020-09-08 15:45:27 +1000) drm fixes for 5.9-rc5 (special edition) i915: - revert gpu relocation changes due to regression msm: - fixes for RPTR corruption issue Dave Airlie (4): Merge tag 'drm-msm-fixes-2020-09-04' of https://gitlab.freedesktop.org/drm/msm into drm-fixes Revert "drm/i915: Remove i915_gem_object_get_dirty_page()" Revert "drm/i915/gem: Async GPU relocations only" Revert "drm/i915/gem: Delete unused code" Jordan Crouse (4): drm/msm: Split the a5xx preemption record drm/msm: Enable expanded apriv support for a650 drm/msm: Disable preemption on all 5xx targets drm/msm: Disable the RPTR shadow drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 314 +++-- drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 + drivers/gpu/drm/i915/gem/i915_gem_pages.c | 14 + .../drm/i915/gem/selftests/i915_gem_execbuffer.c | 21 +- drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 5 + drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 10 + drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 10 + drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 14 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.h | 1 + drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 25 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 13 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c| 27 +- drivers/gpu/drm/msm/msm_gpu.c | 2 +- drivers/gpu/drm/msm/msm_gpu.h | 11 + drivers/gpu/drm/msm/msm_ringbuffer.c | 4 +- 15 files changed, 411 insertions(+), 64 deletions(-)
Re: [PATCH 0/6] ARM: dts: sun8i: v3s: Enable video decoder
Hi, On Fri, Sep 04, 2020 at 10:01:06PM +0200, Martin Cerveny wrote: > First patch extends cedrus capability to all decoders > because V3s missing MPEG2 decoder. > > Next two patches add system control node (SRAM C1) and > next three patches add support for Cedrus VPU. How was it tested? Maxime signature.asc Description: PGP signature
Re: [PATCH V2 5/5] DO NOT MERGE: iommu: disable list appending in dma-iommu
On Tue, Sep 08, 2020 at 02:04:53PM +0800, Lu Baolu wrote: > Do you mind telling where can I find Marek's series? [PATCH v10 00/30] DRM: fix struct sg_table nents vs. orig_nents misuse on various lists including the iommu one.
Re: [PATCH v10 3/3] clk: mediatek: add UART0 clock support
Hi all,
Gentle ping on this patch.
Thanks
Hanks Chen
On Thu, 2020-07-30 at 21:30 +0800, Hanks Chen wrote:
> Add MT6779 UART0 clock support.
>
> Fixes: 710774e04861 ("clk: mediatek: Add MT6779 clock support")
> Signed-off-by: Wendell Lin
> Signed-off-by: Hanks Chen
> Reviewed-by: Matthias Brugger
> ---
> drivers/clk/mediatek/clk-mt6779.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/clk/mediatek/clk-mt6779.c
> b/drivers/clk/mediatek/clk-mt6779.c
> index 9766cccf5844..6e0d3a166729 100644
> --- a/drivers/clk/mediatek/clk-mt6779.c
> +++ b/drivers/clk/mediatek/clk-mt6779.c
> @@ -919,6 +919,8 @@ static const struct mtk_gate infra_clks[] = {
> "pwm_sel", 19),
> GATE_INFRA0(CLK_INFRA_PWM, "infra_pwm",
> "pwm_sel", 21),
> + GATE_INFRA0(CLK_INFRA_UART0, "infra_uart0",
> + "uart_sel", 22),
> GATE_INFRA0(CLK_INFRA_UART1, "infra_uart1",
> "uart_sel", 23),
> GATE_INFRA0(CLK_INFRA_UART2, "infra_uart2",
Re: [PATCH 5/6] media: allwinner,sun4i-a10-video-engine: Add V3s compatible
On Fri, Sep 04, 2020 at 10:01:11PM +0200, Martin Cerveny wrote: > Allwinner V3s SoC contains video engine. Add compatible for it. > > Signed-off-by: Martin Cerveny The prefix isn't the right one, it shouldn't be media: but dt-bindings: media: cedrus: Maxime signature.asc Description: PGP signature
Re: [PATCH v3] i2c: npcm7xx: Fix timeout calculation
On Mon, Aug 31, 2020 at 12:31:21AM +0300, Tali Perry wrote: > timeout_usec value calculation was wrong, the calculated value > was in msec instead of usec. > > Signed-off-by: Tali Perry > Reviewed-by: Avi Fishman Applied to for-current, thanks! And thanks for the Fixes-tag, Joel. signature.asc Description: PGP signature
[PATCH] hwmon: intel-m10-bmc-hwmon: add hwmon support for Intel MAX 10 BMC
This patch adds hwmon functionality for Intel MAX 10 BMC chip. This BMC
chip connects to a set of sensor chips to monitor current, voltage,
thermal and power of different components on board. The BMC firmware is
responsible for sensor data sampling and recording in shared registers.
Host driver reads the sensor data from these shared registers and
exposes them to users as hwmon interfaces.
Signed-off-by: Xu Yilun
Signed-off-by: Wu Hao
Signed-off-by: Matthew Gerlach
Signed-off-by: Tom Rix
---
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/intel-m10-bmc-hwmon.c | 516
3 files changed, 528 insertions(+)
create mode 100644 drivers/hwmon/intel-m10-bmc-hwmon.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 8dc28b2..53af15c 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -2064,6 +2064,17 @@ config SENSORS_XGENE
If you say yes here you get support for the temperature
and power sensors for APM X-Gene SoC.
+config SENSORS_INTEL_M10_BMC_HWMON
+ tristate "Intel MAX10 BMC Hardware Monitoring"
+ depends on MFD_INTEL_M10_BMC
+ help
+ This driver provides support for the hardware monitoring functionality
+ on Intel MAX10 BMC chip.
+
+ This BMC Chip is used on Intel FPGA PCIe Acceleration Cards (PAC). Its
+ sensors monitor various telemetry data of different components on the
+ card, e.g. board temperature, FPGA core temperature/voltage/current.
+
if ACPI
comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index a8f4b35..ba5a25a 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -90,6 +90,7 @@ obj-$(CONFIG_SENSORS_IIO_HWMON) += iio_hwmon.o
obj-$(CONFIG_SENSORS_INA209) += ina209.o
obj-$(CONFIG_SENSORS_INA2XX) += ina2xx.o
obj-$(CONFIG_SENSORS_INA3221) += ina3221.o
+obj-$(CONFIG_SENSORS_INTEL_M10_BMC_HWMON) += intel-m10-bmc-hwmon.o
obj-$(CONFIG_SENSORS_IT87) += it87.o
obj-$(CONFIG_SENSORS_JC42) += jc42.o
obj-$(CONFIG_SENSORS_K8TEMP) += k8temp.o
diff --git a/drivers/hwmon/intel-m10-bmc-hwmon.c
b/drivers/hwmon/intel-m10-bmc-hwmon.c
new file mode 100644
index 000..43e55e7
--- /dev/null
+++ b/drivers/hwmon/intel-m10-bmc-hwmon.c
@@ -0,0 +1,516 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel MAX 10 BMC HWMON Driver
+ *
+ * Copyright (C) 2018-2020 Intel Corporation. All rights reserved.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum m10bmc_channel_type {
+ M10BMC_CHT_TEMP,
+ M10BMC_CHT_IN,
+ M10BMC_CHT_CURR,
+ M10BMC_CHT_POWER,
+ M10BMC_CHT_MAX,
+};
+
+struct m10bmc_sdata {
+ unsigned int type;
+ unsigned int reg_input;
+ unsigned int reg_max;
+ unsigned int reg_crit;
+ unsigned int reg_hyst;
+ unsigned int reg_min;
+ unsigned int multiplier;
+ const char *label;
+};
+
+static struct m10bmc_sdata n3000bmc_sensor_tbl[] = {
+ { M10BMC_CHT_TEMP, 0x100, 0x104, 0x108, 0x10c, 0x0, 500,
+"Board Temperature" },
+ { M10BMC_CHT_TEMP, 0x110, 0x114, 0x118, 0x0, 0x0, 500,
+"FPGA Die Temperature" },
+ { M10BMC_CHT_TEMP, 0x11c, 0x120, 0x124, 0x0, 0x0, 500,
+"QSFP0 Temperature" },
+ { M10BMC_CHT_IN, 0x128, 0x0, 0x0, 0x0, 0x0, 1,
+"QSFP0 Supply Voltage" },
+ { M10BMC_CHT_TEMP, 0x12c, 0x130, 0x134, 0x0, 0x0, 500,
+"QSFP1 Temperature" },
+ { M10BMC_CHT_IN, 0x138, 0x0, 0x0, 0x0, 0x0, 1,
+"QSFP1 Supply Voltage" },
+ { M10BMC_CHT_IN, 0x13c, 0x0, 0x0, 0x0, 0x0, 1,
+"FPGA Core Voltage" },
+ { M10BMC_CHT_CURR, 0x140, 0x0, 0x0, 0x0, 0x0, 1,
+"FPGA Core Current" },
+ { M10BMC_CHT_IN, 0x144, 0x0, 0x0, 0x0, 0x0, 1,
+"12V Backplane Voltage" },
+ { M10BMC_CHT_CURR, 0x148, 0x0, 0x0, 0x0, 0x0, 1,
+"12V Backplane Current" },
+ { M10BMC_CHT_IN, 0x14c, 0x0, 0x0, 0x0, 0x0, 1,
+"1.2V Voltage" },
+ {M10BMC_CHT_IN, 0x150, 0x0, 0x0, 0x0, 0x0, 1,
+"12V AUX Voltage" },
+ { M10BMC_CHT_CURR, 0x154, 0x0, 0x0, 0x0, 0x0, 1,
+"12V AUX Current" },
+ { M10BMC_CHT_IN, 0x158, 0x0, 0x0, 0x0, 0x0, 1,
+"1.8V Voltage" },
+ { M10BMC_CHT_IN, 0x15c, 0x0, 0x0, 0x0, 0x0, 1,
+"3.3V Voltage" },
+ { M10BMC_CHT_POWER, 0x160, 0x0, 0x0, 0x0, 0x0, 1000,
+"Board Power" },
+ { M10BMC_CHT_TEMP, 0x168, 0x0, 0x0, 0x0, 0x0, 500,
+"Retimer A Temperature" },
+ { M10BMC_CHT_TEMP, 0x16c, 0x0, 0x0, 0x0, 0x0, 500,
+"Retimer A SerDes Temperature" },
+ { M10BMC_CHT_TEMP, 0x170, 0x0, 0x0, 0x0, 0x0, 500,
+"Retimer B Temperature" },
+ { M10BMC_CHT_TEMP, 0x174, 0x0, 0x0, 0x0, 0x0, 500,
+"Retimer B SerDes Temperature" },
+ { M10BMC_CHT_MAX } /* sentinel */
+};
+
+struct m10bmc_ch_group {
+ int num_channels;
+
[PATCH] add hwmon support for Intel MAX 10 BMC
This patch depends on the patch "add Intel MAX 10 BMC chip support for Intel FPGA PAC". https://lore.kernel.org/lkml/1599491813-20819-1-git-send-email-yilun...@intel.com/ This patch adds support for the hwmon sub device in Intel MAX 10 BMC Xu Yilun (1): hwmon: intel-m10-bmc-hwmon: add hwmon support for Intel MAX 10 BMC drivers/hwmon/Kconfig | 11 + drivers/hwmon/Makefile | 1 + drivers/hwmon/intel-m10-bmc-hwmon.c | 516 3 files changed, 528 insertions(+) create mode 100644 drivers/hwmon/intel-m10-bmc-hwmon.c -- 2.7.4
[PATCH v3] debugobjects: install CPU hotplug callback
From: Zqiang
Due to CPU hotplug, it may never be online after it's offline,
some objects in percpu pool is never free. in order to avoid
this happening, install CPU hotplug callback, call this callback
func to free objects in percpu pool when CPU going offline.
Signed-off-by: Zqiang
---
v1->v2:
Modify submission information.
v2->v3:
In CPU hotplug callback func, add clear percpu pool "obj_free" operation.
capitalize 'CPU', and use shorter preprocessor sequence.
include/linux/cpuhotplug.h | 1 +
lib/debugobjects.c | 24
2 files changed, 25 insertions(+)
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 3215023d4852..0c39d57e5342 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -36,6 +36,7 @@ enum cpuhp_state {
CPUHP_X86_MCE_DEAD,
CPUHP_VIRT_NET_DEAD,
CPUHP_SLUB_DEAD,
+ CPUHP_DEBUG_OBJ_DEAD,
CPUHP_MM_WRITEBACK_DEAD,
CPUHP_MM_VMSTAT_DEAD,
CPUHP_SOFTIRQ_DEAD,
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index fe4557955d97..bb69a02c3e7b 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#define ODEBUG_HASH_BITS 14
#define ODEBUG_HASH_SIZE (1 << ODEBUG_HASH_BITS)
@@ -433,6 +434,24 @@ static void free_object(struct debug_obj *obj)
}
}
+#ifdef CONFIG_HOTPLUG_CPU
+static int object_cpu_offline(unsigned int cpu)
+{
+ struct debug_percpu_free *percpu_pool;
+ struct hlist_node *tmp;
+ struct debug_obj *obj;
+
+ percpu_pool = per_cpu_ptr(_obj_pool, cpu);
+ hlist_for_each_entry_safe(obj, tmp, _pool->free_objs, node) {
+ hlist_del(>node);
+ kmem_cache_free(obj_cache, obj);
+ }
+ percpu_pool->obj_free = 0;
+
+ return 0;
+}
+#endif
+
/*
* We run out of memory. That means we probably have tons of objects
* allocated.
@@ -1367,6 +1386,11 @@ void __init debug_objects_mem_init(void)
} else
debug_objects_selftest();
+#ifdef CONFIG_HOTPLUG_CPU
+ cpuhp_setup_state_nocalls(CPUHP_DEBUG_OBJ_DEAD, "object:offline", NULL,
+ object_cpu_offline);
+#endif
+
/*
* Increase the thresholds for allocating and freeing objects
* according to the number of possible CPUs available in the system.
--
2.17.1
Re: Re: [PATCH v2 0/2] Remove MT6779 UART3 clock support
Hi all, Gentle ping on this patch set. Thanks! Hanks Chen On Thu, 2020-07-30 at 21:04 +0800, Hanks Chen wrote: > Hi all, > > Gentle ping on this patch. > > Thanks! > > Hanks Chen > > > On Wed, 2020-07-22 at 17:21 +0200, Matthias Brugger wrote: > > > > On 22/07/2020 13:16, Hanks Chen wrote: > > > On Wed, 2020-07-22 at 10:43 +0200, Matthias Brugger wrote: > > >> > > >> On 22/07/2020 05:09, Hanks Chen wrote: > > >>> remove the redundant clk interface of uart. > > >>> CLK_INFRA_UART3 is a dummy clk interface, > > >>> it has no effect on the operation of the read/write instruction. > > >>> > > >>> Change since v2: > > >>> Commit "dt-bindings: clock: remove UART3 clock support" > > >> > > >> Sorry just another comment. I think we can make this one patch deleting > > >> everything. > > >> > > > Sorry, I don't understand the comment. Do I need to merge them into one > > > big patch? > > > Btw, if I use one patch, I would get check patch fail. > > > --- > > > [2020-07-22 19:12:49,046 ERROR] Run check patch results: > > > WARNING:DT_SPLIT_BINDING_PATCH: DT binding docs and includes should be a > > > separate patch. See: > > > Documentation/devicetree/bindings/submitting-patches.rst > > > --- > > > > Hm, I think that's a debatable error message from checkpatch, but let's > > leave it > > as it is. > > > > Regards, > > Matthias > > > > > > > > > > Hanks > > > > > >>> -- remove Fixes tag > > >>> Commit "clk: mediatek: remove UART3 clock support" > > >>> -- remove Fixes tag > > >>> > > >>> Hanks Chen (2): > > >>> dt-bindings: clock: remove UART3 clock support > > >>> clk: mediatek: remove UART3 clock support > > >>> > > >>>drivers/clk/mediatek/clk-mt6779.c | 2 -- > > >>>include/dt-bindings/clock/mt6779-clk.h | 1 - > > >>>2 files changed, 3 deletions(-) > > >>> > > > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
[PATCH] x86, fakenuma: Avoid too large emulated node
On a testing system with 2 physical NUMA node, 8GB memory, a small memory hole from 640KB to 1MB, and a large memory hole from 3GB to 4GB. If "numa=fake=1G" is used in kernel command line, the resulting fake NUMA nodes are as follows, NUMA: Node 0 [mem 0x-0x0009] + [mem 0x0010-0xbfff] -> [mem 0x-0xbfff] NUMA: Node 0 [mem 0x-0xbfff] + [mem 0x1-0x13fff] -> [mem 0x-0x13fff] Faking node 0 at [mem 0x-0x41ff] (1056MB) Faking node 1 at [mem 0x00014000-0x00017fff] (1024MB) Faking node 2 at [mem 0x4200-0x81ff] (1024MB) Faking node 3 at [mem 0x00018000-0x0001bfff] (1024MB) Faking node 4 at [mem 0x8200-0x00013fff] (3040MB) Faking node 5 at [mem 0x0001c000-0x0001] (1024MB) Faking node 6 at [mem 0x0002-0x00023fff] (1024MB) Where, 7 fake NUMA nodes are emulated, the size of fake node 4 is 3040 - 1024 = 2016MB. This is nearly 2 times of the size of the other fake nodes (about 1024MB). This isn't a reasonable splitting. The better way is to make the fake node size not too large or small. So in this patch, the splitting algorithm is changed to make the fake node size between 1/2 to 3/2 of the specified node size. After applying this patch, the resulting fake NUMA nodes become, Faking node 0 at [mem 0x-0x41ff] (1056MB) Faking node 1 at [mem 0x00014000-0x00017fff] (1024MB) Faking node 2 at [mem 0x4200-0x81ff] (1024MB) Faking node 3 at [mem 0x00018000-0x0001bfff] (1024MB) Faking node 4 at [mem 0x8200-0x000103ff] (2080MB) Faking node 5 at [mem 0x0001c000-0x0001] (1024MB) Faking node 6 at [mem 0x00010400-0x00013fff] (960MB) Faking node 7 at [mem 0x0002-0x00023fff] (1024MB) The newly added node 6 is a little smaller than the specified node size (960MB vs. 1024MB). But the overall results look more reasonable. Signed-off-by: "Huang, Ying" Cc: Andrew Morton Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Dan Williams Cc: David Rientjes Cc: Dave Jiang --- arch/x86/mm/numa_emulation.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/numa_emulation.c b/arch/x86/mm/numa_emulation.c index 683cd12f4793..231469e1de6a 100644 --- a/arch/x86/mm/numa_emulation.c +++ b/arch/x86/mm/numa_emulation.c @@ -300,9 +300,10 @@ static int __init split_nodes_size_interleave_uniform(struct numa_meminfo *ei, /* * If there won't be enough non-reserved memory for the * next node, this one must extend to the end of the -* physical node. +* physical node. The size of the emulated node should +* be between size/2 and size*3/2. */ - if ((limit - end - mem_hole_size(end, limit) < size) + if ((limit - end - mem_hole_size(end, limit) < size / 2) && !uniform) end = limit; -- 2.28.0
[PATCH] usb: serial: Repair FTDI FT232R bricked eeprom
This patch detects end reverses the effects of the malicious FTDI
Windows driver version 2.12.00(FTDIgate).
While we currently load the ftdi_sio driver for devices with
FTDI_BRICK_PID(0x) userspace applications that expect the
appropriate FTDI_8U232AM_PID(0x6001) PID may not work properly.
Since the malicious FTDI driver modifies the PID without modifying
the normal checksum field we can detect and limit the unbricking
to devices that were bricked specifically using the FTDI checksum
preimage attack technique used by the official Windows drivers.
This should have no effect on devices where the PID was deliberately
set to FTDI_BRICK_PID(0x) as the checksum would normally change
and the preimage target(address 62) should be 0. We validate that
the preimage target is not 0 before attempting to unbrick.
Since we only write to even addresses this should have no effect at
all on non-counterfeit FTDI hardware due to the hardware only
committing EEPROM writes when odd addresses are written.
References:
https://marcan.st/transf/detect_ftdi_clone.py
https://hackaday.com/2014/10/22/watch-that-windows-update-ftdi-drivers-are-killing-fake-chips/
https://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-ftdi-ft232/msg535270/#msg535270
https://lkml.org/lkml/2014/10/23/266
https://lore.kernel.org/patchwork/patch/509929/
https://lore.kernel.org/patchwork/patch/510097/
Signed-off-by: Russ Dill
Signed-off-by: James Hilliard
Cc: Hector Martin
---
drivers/usb/serial/ftdi_sio.c | 112 ++
drivers/usb/serial/ftdi_sio.h | 4 ++
2 files changed, 116 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 871cdccf3a5f..39fc14af6185 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -2029,6 +2029,22 @@ static int ftdi_read_eeprom(struct usb_serial *serial,
void *dst, u16 addr,
return 0;
}
+static int ftdi_write_eeprom(struct usb_serial_port *port, u8 addr, u16 data)
+{
+ struct usb_device *udev = port->serial->dev;
+ int rv;
+
+ rv = usb_control_msg(udev,
+usb_sndctrlpipe(udev, 0),
+FTDI_SIO_WRITE_EEPROM_REQUEST,
+FTDI_SIO_WRITE_EEPROM_REQUEST_TYPE,
+data, addr,
+NULL, 0, WDR_TIMEOUT);
+ if (rv < 0)
+ dev_err(>dev, "Unable to write EEPROM: %i\n", rv);
+ return rv;
+}
+
static int ftdi_gpio_init_ft232h(struct usb_serial_port *port)
{
struct ftdi_private *priv = usb_get_serial_port_data(port);
@@ -2234,10 +2250,100 @@ static int ftdi_sio_probe(struct usb_serial *serial,
return 0;
}
+static u16 ftdi_checksum(u16 *data, int n)
+{
+ u16 checksum;
+ int i;
+
+ checksum = 0x;
+ for (i = 0; i < n - 1; i++) {
+ checksum ^= be16_to_cpu(data[i]);
+ checksum = (checksum << 1) | (checksum >> 15);
+ }
+
+ return cpu_to_be16(checksum);
+}
+
+static int ftdi_repair_brick(struct usb_serial_port *port)
+{
+ struct ftdi_private *priv = usb_get_serial_port_data(port);
+ int orig_latency;
+ int rv;
+ u16 *eeprom_data;
+ u16 checksum;
+ int eeprom_size;
+ int result;
+
+ switch (priv->chip_type) {
+ case FT232RL:
+ eeprom_size = 0x40;
+ break;
+ default:
+ /* Unsupported for brick repair */
+ return 0;
+ }
+
+ /* Latency timer needs to be 0x77 to unlock EEPROM programming */
+ if (priv->latency != 0x77) {
+ orig_latency = priv->latency;
+ priv->latency = 0x77;
+ rv = write_latency_timer(port);
+ priv->latency = orig_latency;
+ if (rv < 0)
+ return -EIO;
+ }
+
+ eeprom_data = kmalloc(eeprom_size * 2, GFP_KERNEL);
+ if (!eeprom_data)
+ return -ENOMEM;
+
+ /* Read in EEPROM */
+ result = ftdi_read_eeprom(port->serial, eeprom_data, 0x00, eeprom_size
* 2);
+ if (result < 0)
+ goto end_repair_brick;
+
+ /* Verify EEPROM is valid */
+ checksum = ftdi_checksum(eeprom_data, eeprom_size);
+ if (checksum != eeprom_data[eeprom_size - 1])
+ goto end_repair_brick;
+
+ /* FTDI driver checksum preimage attack targets address 62 */
+ if (eeprom_data[62] == 0)
+ goto end_repair_brick;
+
+ /* Attempt to restore Product ID to 0x6001 */
+ eeprom_data[2] = FTDI_8U232AM_PID;
+
+ /* Clear preimage attack target address */
+ eeprom_data[62] = 0;
+
+ /* Calculate and verify new checksum */
+ checksum = ftdi_checksum(eeprom_data, eeprom_size);
+ if (checksum != eeprom_data[eeprom_size - 1])
+ goto end_repair_brick;
+
+ /* Restore EEPROM PID to original pre-brick state */
+
Apply from 2018? [V2,0/3] phy: qcom-ipq4019-usb: add new driver
Alban, Andy, Can you please apply this patch series from 2018 or please explain what I (or John) have to do so this series can be applied? https://patchwork.kernel.org/cover/10552139/ [V2,0/3] phy: qcom-ipq4019-usb: add new driver OpenWRT has been applying this code to all ipq4019 targets since Jul 2018: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=95672e04335ea0d7d8f468cec8f63d593cc6ede6 I expect if there were problems with it, we'd know by now. $ find -name \*qcom-ipq4019-usb\* ./target/linux/ipq40xx/patches-5.4/076-phy-qcom-ipq4019-usb-add-driver-for-QCOM-IPQ4019.patch ./target/linux/ipq40xx/patches-5.4/075-dt-bindings-phy-qcom-ipq4019-usb-add-binding-documen.patch ./target/linux/ipq40xx/patches-4.19/076-phy-qcom-ipq4019-usb-add-driver-for-QCOM-IPQ4019.patch ./target/linux/ipq40xx/patches-4.19/075-dt-bindings-phy-qcom-ipq4019-usb-add-binding-documen.patch ... In 2018, Rob Herring reviewed (and approved): [V2,1/3] dt-bindings: phy-qcom-ipq4019-usb: add binding document I've just reviewed 2/3 and 3/3. You can add to those: Reviewed-by: Grant Grundler I compared 3/3 with the DTS entries that were submitted (and I approved) to chromeos-3.18 kernel tree in 2016: https://chromium-review.googlesource.com/337605 https://chromium-review.googlesource.com/344471 While not identical, the important bits (reg values) are. (I would reply to the original thread but I don't have it in a format I can easily reply to.) cheers, grant
Re: Apply from 2018? [V2,0/3] phy: qcom-ipq4019-usb: add new driver
Adding linux-...@vger.kernel.org since Andy's email in MAINTAINERs bounced. Using Matthew's personal email since his codeaurora email bounced. On Mon, Sep 7, 2020 at 11:35 PM Grant Grundler wrote: > > Alban, Andy, > Can you please apply this patch series from 2018 or please explain > what I (or John) have to do so this series can be applied? > >https://patchwork.kernel.org/cover/10552139/ >[V2,0/3] phy: qcom-ipq4019-usb: add new driver > > OpenWRT has been applying this code to all ipq4019 targets since Jul 2018: > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=95672e04335ea0d7d8f468cec8f63d593cc6ede6 > > I expect if there were problems with it, we'd know by now. > > $ find -name \*qcom-ipq4019-usb\* > ./target/linux/ipq40xx/patches-5.4/076-phy-qcom-ipq4019-usb-add-driver-for-QCOM-IPQ4019.patch > ./target/linux/ipq40xx/patches-5.4/075-dt-bindings-phy-qcom-ipq4019-usb-add-binding-documen.patch > ./target/linux/ipq40xx/patches-4.19/076-phy-qcom-ipq4019-usb-add-driver-for-QCOM-IPQ4019.patch > ./target/linux/ipq40xx/patches-4.19/075-dt-bindings-phy-qcom-ipq4019-usb-add-binding-documen.patch > ... > > In 2018, Rob Herring reviewed (and approved): >[V2,1/3] dt-bindings: phy-qcom-ipq4019-usb: add binding document > > I've just reviewed 2/3 and 3/3. You can add to those: > Reviewed-by: Grant Grundler > > I compared 3/3 with the DTS entries that were submitted (and I > approved) to chromeos-3.18 kernel tree in 2016: >https://chromium-review.googlesource.com/337605 >https://chromium-review.googlesource.com/344471 > > While not identical, the important bits (reg values) are. > > (I would reply to the original thread but I don't have it in a format > I can easily reply to.) > > cheers, > grant
Re: [PATCH v2 0/4] qla2xxx: A couple crash fixes
Hi Daniel, On Mon, 31 Aug 2020, 9:18am, Daniel Wagner wrote: > changes since v1: > > - added dummy warn function to patch#1 > - added log entry to patch#4 > > as suggested by Martin > > > > Initial cover letter: > > The first crash we observed is due memory corruption in the srb memory > pool. Unforuntatly, I couldn't find the source of the problem but the > workaround by resetting the cleanup callbacks 'fixes' this problem > (patch #1). I think as intermeditate step this should be merged until > the real cause can be identified. > > The second crash is due a race condition(?) in the firmware. The sts > entries are not updated in time which leads to this crash pattern > which several customers have reported: > > #0 [c0d1bb80] scsi_dma_unmap at d0001e4904d4 [scsi_mod] > #1 [c0d1bbe0] qla2x00_sp_compl at d000204803cc [qla2xxx] > #2 [c0d1bc20] qla24xx_process_response_queue at d000204c5810 > [qla2xxx] > #3 [c0d1bd50] qla24xx_msix_rsp_q at d000204c8fd8 [qla2xxx] > #4 [c0d1bde0] __handle_irq_event_percpu at c0189510 > #5 [c0d1bea0] handle_irq_event_percpu at c018978c > #6 [c0d1bee0] handle_irq_event at c018984c > #7 [c0d1bf10] handle_fasteoi_irq at c018efc0 > #8 [c0d1bf40] generic_handle_irq at c0187f10 > #9 [c0d1bf60] __do_irq at c0018784 > #10 [c0d1bf90] call_do_irq at c002caa4 > #11 [c0ecca417a00] do_IRQ at c0018970 > #12 [c0ecca417a50] restore_check_irq_replay at c000de98 > > From analyzing the crash dump it was clear that > qla24xx_mbx_iocb_entry() calls sp->done (qla2x00_sp_compl) which > crashes because the response is not a mailbox entry, it is a status > entry. Patch #4 changes the process logic for mailbox commands so that > the sp is parsed before calling the correct proccess function. > > Thanks, > Daniel > > Daniel Wagner (4): > qla2xxx: Warn if done() or free() are called on an already freed srb > qla2xxx: Simplify return value logic in qla2x00_get_sp_from_handle() > qla2xxx: Drop unused function argument from > qla2x00_get_sp_from_handle() > qla2xxx: Handle incorrect entry_type entries > > drivers/scsi/qla2xxx/qla_gbl.h| 3 +- > drivers/scsi/qla2xxx/qla_init.c | 10 ++ > drivers/scsi/qla2xxx/qla_inline.h | 5 +++ > drivers/scsi/qla2xxx/qla_isr.c| 74 > +++ > drivers/scsi/qla2xxx/qla_mr.c | 9 ++--- > 5 files changed, 62 insertions(+), 39 deletions(-) > > Thanks for the patches, my comments in the respective patches. Regards, -Arun
Re: [PATCH v6 04/13] usb: dwc3: Add splitdisable quirk for Hisilicon Kirin Soc
Em Mon, 07 Sep 2020 17:04:31 +0300
Felipe Balbi escreveu:
> >> static const struct dev_pm_ops dwc3_dev_pm_ops = {
> >>SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
> >> + .complete = dwc3_complete,
>
> why is this done on complete? Why can't it be done at the end of
> dwc3_resume()?
Updating my answer:
No. I just tested moving the code from .complete to the end of
.resume. After moving it, the HID won't be able to properly enable
the device at resume time (logs filtered to show only relevant msgs):
# echo reboot > /sys/power/disk; echo disk > /sys/power/state
...
[ 29.051314] Freezing user space processes ... (elapsed 0.001
seconds) done.
[ 29.059811] OOM killer disabled.
[ 30.171526] PM: hibernation: Creating image:
[ 30.171526] PM: hibernation: Need to copy 164192 pages
[ 30.171526] PM: hibernation: Image created (164192 pages copied)
[ 30.171644] Enabling non-boot CPUs ...
[ 30.293953] dwc3 ff10.dwc3: dwc3_resume
[ 30.424549] usb usb1-port1: status 0101 change 0001
[ 30.428538] usb usb2-port1: status 0203 change 0001
[ 30.536609] usb 1-1: Waited 0ms for CONNECT
[ 30.543822] usb 1-1: finish reset-resume
[ 30.544619] usb 2-1: Waited 0ms for CONNECT
[ 30.558869] usb 2-1: finish reset-resume
[ 30.676706] usb 1-1: reset high-speed USB device number 2 using
xhci-hcd
[ 30.882194] hub 1-1:1.0: hub_reset_resume
[ 30.888479] hub 1-1:1.0: enabling power on all ports
[ 30.960767] usb 2-1: reset SuperSpeed Gen 1 USB device number 2
using xhci-hcd
[ 30.994229] hub 2-1:1.0: hub_reset_resume
[ 31.000574] usb 1-1-port1: status 0301 change 0001
[ 31.002088] hub 2-1:1.0: enabling power on all ports
[ 31.009079] usb 1-1-port2: status 0101 change 0001
[ 31.132633] usb 1-1.2: Waited 0ms for CONNECT
[ 31.132665] usb 1-1.1: Waited 0ms for CONNECT
[ 31.140560] usb 1-1.2: finish reset-resume
[ 31.148509] usb 1-1.1: finish reset-resume
[ 31.240760] usb 1-1.2: reset high-speed USB device number 4 using
xhci-hcd
[ 32.471492] dwc3 ff10.dwc3: dwc3_complete
[ 32.480512] PM: Cannot find swap device, try swapon -a
[ 32.489532] PM: Cannot get swap writer
[ 32.575790] Restarting tasks ...
[ 32.575891] hub 1-0:1.0: state 7 ports 1 chg evt
[ 32.575894] hub 2-0:1.0: state 7 ports 1 chg evt
[ 32.575896] hub 1-1:1.0: state 7 ports 4 chg evt 0002
[ 32.576570] hub 2-1:1.0: state 7 ports 4 chg evt
[ 32.576876] done.
[ 32.600094] hub 2-1:1.0: hub_suspend
[ 32.642090] PM: hibernation: hibernation exit
[ 32.650255] usb 2-1: usb auto-suspend, wakeup 1
[ 32.668581] hub 2-0:1.0: hub_suspend
[ 33.122384] hub 1-1:1.0: state 7 ports 4 chg evt 0002
[ 33.378220] usb 1-1.1: reset low-speed USB device number 3 using
xhci-hcd
[ 33.698394] hub 1-1:1.0: state 7 ports 4 chg evt
[ 34.882365] hub 1-1:1.0: state 7 ports 4 chg evt 0002
[ 35.138217] usb 1-1.1: reset low-speed USB device number 3 using
xhci-hcd
[ 35.458617] hub 1-1:1.0: state 7 ports 4 chg evt
[ 36.642392] hub 1-1:1.0: state 7 ports 4 chg evt 0002
[ 36.898207] usb 1-1.1: reset low-speed USB device number 3 using
xhci-hcd
[ 37.218598] hub 1-1:1.0: state 7 ports 4 chg evt
[ 37.672658] kirin9xx-drm e860.dpe: [drm:dss_disable_vblank
[kirin9xx_drm]] dss_disable_vblank
[ 38.402368] hub 1-1:1.0: state 7 ports 4 chg evt 0002
[ 38.658174] usb 1-1.1: reset low-speed USB device number 3 using
xhci-hcd
[ 38.978594] hub 1-1:1.0: state 7 ports 4 chg evt
[ 40.162361] hub 1-1:1.0: state 7 ports 4 chg evt 0002
[ 40.418148] usb 1-1.1: reset low-speed USB device number 3 using
xhci-hcd
...
[ 397.698132] usb 1-1.1: reset low-speed USB device number 3 using
xhci-hcd
[ 398.018565] hub 1-1:1.0: state 7 ports 4 chg evt
Basically, after resume, the code behaves just like the quirk were
not applied.
Explaining with more details, without the splitdisable quirk, what
happens is that the USB URBs return -EPROTO errors, causing
hid-core.c to call hid_io_error(). This function starts a reset
work (usbhid->reset_work), which ends calling (at hid_reset()):
usb_queue_reset_device(usbhid->intf);
This happens on every HZ/2 intervals, causing an endless reset
loop.
Thanks,
Mauro
Re: [PATCH v2 1/4] qla2xxx: Warn if done() or free() are called on an already freed srb
On Mon, 31 Aug 2020, 9:18am, Daniel Wagner wrote:
>
> Emit a warning when ->done or ->free are called on an already freed
> srb. There is a hidden use-after-free bug in the driver which corrupts
> the srb memory pool which originates from the cleanup callbacks. By
> explicitly resetting the callbacks to NULL, we workaround the memory
> corruption.
>
> An extensive search didn't bring any lights on the real problem. The
> initial idea was to set both pointers to NULL and try to catch invalid
> accesses. But instead the memory corruption was gone and the driver
> didn't crash.
>
> Signed-off-by: Daniel Wagner
> ---
> drivers/scsi/qla2xxx/qla_init.c | 10 ++
> drivers/scsi/qla2xxx/qla_inline.h | 5 +
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
> index 57a2d76aa691..9e9360a4aeb5 100644
> --- a/drivers/scsi/qla2xxx/qla_init.c
> +++ b/drivers/scsi/qla2xxx/qla_init.c
> @@ -63,6 +63,16 @@ void qla2x00_sp_free(srb_t *sp)
> qla2x00_rel_sp(sp);
> }
>
> +void qla2xxx_rel_done_warning(srb_t *sp, int res)
> +{
> + WARN_ONCE(1, "Calling done() of an already freed srb object\n");
> +}
> +
> +void qla2xxx_rel_free_warning(srb_t *sp)
> +{
> + WARN_ONCE(1, "Calling free() of an already freed srb object\n");
> +}
Please print the address of srb too for the above two functions.
With that, looks good.
Regards,
-Arun
Re: [PATCH] mm/mmu_notifier.c: micro-optimization substitute kzalloc with kmalloc
On Sun, Sep 06, 2020 at 06:06:39PM +0200, Mateusz Nosek wrote: > Hi, > > I performed simple benchmarks using custom kernel module with the code > fragment in question 'copy-pasted' in there in both versions. In case of 1k, > 10k and 100k iterations the average time for kzalloc version was 5.1 and for > kmalloc 3.9, for each iterations number. > The time was measured using 'ktime_get(void)' function and the results given > here are in ktime_t units. > The machine I use has 4 core Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz CPU. > > The performance increase happens, but as you wrote it is probably not really > noticeable. I don't think that saving a few cylces of memset() in a function that called only on the initialization path in very particular cases is worth risking uninitialized variables when somebody will add a new field to the 'struct mmu_notifier_subscriptions' and will forget to explicitly set it. > I have found 3 other places in kernel code with similar kzalloc related > issues, none of which seems to be 'hot' code. > I leave the decision if this patch and potential others I would send > regarding this issue, are worth applying to the community and maintainers. > > Best regards, > Mateusz Nosek > > On 9/6/2020 4:26 PM, Mike Rapoport wrote: > > Hi, > > > > On Sun, Sep 06, 2020 at 01:43:21PM +0200, mateusznos...@gmail.com wrote: > > > From: Mateusz Nosek > > > > > > Most fields in struct pointed by 'subscriptions' are initialized > > > explicitly > > > after the allocation. By changing kzalloc to kmalloc the call to memset > > > is avoided. As the only new code consists of 2 simple memory accesses, > > > the performance is increased. > > > > Is there a measurable performance increase? > > > > The __mmu_notifier_register() is not used that frequently to trade off > > robustness of kzalloc() for slight (if visible at all) performance gain. > > > > > Signed-off-by: Mateusz Nosek > > > --- > > > mm/mmu_notifier.c | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c > > > index 4fc918163dd3..190e198dc5be 100644 > > > --- a/mm/mmu_notifier.c +++ b/mm/mmu_notifier.c @@ -625,7 +625,7 > > > @@ int __mmu_notifier_register(struct mmu_notifier *subscription, > > > * know that mm->notifier_subscriptions can't change while we * > > > hold the write side of the mmap_lock. */ > > > - subscriptions = kzalloc( > > > + subscriptions = kmalloc( > > > sizeof(struct mmu_notifier_subscriptions), > > > GFP_KERNEL); > > > if (!subscriptions) > > > return -ENOMEM; > > > @@ -636,6 +636,8 @@ int __mmu_notifier_register(struct mmu_notifier > > > *subscription, > > > subscriptions->itree = RB_ROOT_CACHED; > > > init_waitqueue_head(>wq); > > > INIT_HLIST_HEAD(>deferred_list); > > > + subscriptions->active_invalidate_ranges = 0; > > > + subscriptions->has_itree = false; > > > } > > > ret = mm_take_all_locks(mm); > > > -- > > > 2.20.1 > > > > > > > > -- Sincerely yours, Mike.
Re: [PATCH v2 2/4] qla2xxx: Simplify return value logic in qla2x00_get_sp_from_handle()
On Mon, 31 Aug 2020, 9:18am, Daniel Wagner wrote:
>
> Refactor qla2x00_get_sp_from_handle() to avoid the unecessary
> goto if early returns are used. With this we can also avoid
> preinitilzing the sp pointer.
>
> Signed-off-by: Daniel Wagner
> ---
> drivers/scsi/qla2xxx/qla_isr.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
> index 27bcd346af7c..5d278155e4e7 100644
> --- a/drivers/scsi/qla2xxx/qla_isr.c
> +++ b/drivers/scsi/qla2xxx/qla_isr.c
> @@ -1716,7 +1716,7 @@ qla2x00_get_sp_from_handle(scsi_qla_host_t *vha, const
> char *func,
> {
> struct qla_hw_data *ha = vha->hw;
> sts_entry_t *pkt = iocb;
> - srb_t *sp = NULL;
> + srb_t *sp;
> uint16_t index;
>
> index = LSW(pkt->handle);
> @@ -1728,13 +1728,13 @@ qla2x00_get_sp_from_handle(scsi_qla_host_t *vha,
> const char *func,
> set_bit(FCOE_CTX_RESET_NEEDED, >dpc_flags);
> else
> set_bit(ISP_ABORT_NEEDED, >dpc_flags);
> - goto done;
> + return NULL;
> }
> sp = req->outstanding_cmds[index];
> if (!sp) {
> ql_log(ql_log_warn, vha, 0x5032,
> "Invalid completion handle (%x) -- timed-out.\n", index);
> - return sp;
> + return NULL;
> }
> if (sp->handle != index) {
> ql_log(ql_log_warn, vha, 0x5033,
> @@ -1743,8 +1743,6 @@ qla2x00_get_sp_from_handle(scsi_qla_host_t *vha, const
> char *func,
> }
>
> req->outstanding_cmds[index] = NULL;
> -
> -done:
> return sp;
> }
>
Looks good.
Regards,
-Arun
[PATCH 1/4] scsi: ufs-mediatek: Eliminate error message for unbound mphy
Some MediaTek platforms does not have to bind MPHY so users
shall not see any unnecessary logs. Simply remove logs for this
case.
Fixes: fc4983018fea ("scsi: ufs-mediatek: Allow unbound mphy")
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs-mediatek.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 29cd017c1aa0..7487b25fa651 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -129,7 +129,10 @@ static int ufs_mtk_bind_mphy(struct ufs_hba *hba)
__func__, err);
} else if (IS_ERR(host->mphy)) {
err = PTR_ERR(host->mphy);
- dev_info(dev, "%s: PHY get failed %d\n", __func__, err);
+ if (err != -ENODEV) {
+ dev_info(dev, "%s: PHY get failed %d\n", __func__,
+err);
+ }
}
if (err)
--
2.18.0
[PATCH 3/4] scsi: ufs-mediatek: Fix flag of unipro low-power mode
Forcibly leave UniPro low-power mode if UIC commands is failed.
This makes hba_enable_delay_us as correct (default) value for
re-enabling the host.
At the same time, change type of parameter "lpm" in function
ufs_mtk_unipro_set_pm() to "bool".
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs-mediatek.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 887c03e8bcc0..feba74a72309 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -419,7 +419,7 @@ static int ufs_mtk_pwr_change_notify(struct ufs_hba *hba,
return ret;
}
-static int ufs_mtk_unipro_set_pm(struct ufs_hba *hba, u32 lpm)
+static int ufs_mtk_unipro_set_pm(struct ufs_hba *hba, bool lpm)
{
int ret;
struct ufs_mtk_host *host = ufshcd_get_variant(hba);
@@ -427,8 +427,14 @@ static int ufs_mtk_unipro_set_pm(struct ufs_hba *hba, u32
lpm)
ret = ufshcd_dme_set(hba,
UIC_ARG_MIB_SEL(VS_UNIPROPOWERDOWNCONTROL, 0),
lpm);
- if (!ret)
+ if (!ret || !lpm) {
+ /*
+* Forcibly set as non-LPM mode if UIC commands is failed
+* to use default hba_enable_delay_us value for re-enabling
+* the host.
+*/
host->unipro_lpm = lpm;
+ }
return ret;
}
@@ -438,7 +444,9 @@ static int ufs_mtk_pre_link(struct ufs_hba *hba)
int ret;
u32 tmp;
- ufs_mtk_unipro_set_pm(hba, 0);
+ ret = ufs_mtk_unipro_set_pm(hba, false);
+ if (ret)
+ return ret;
/*
* Setting PA_Local_TX_LCC_Enable to 0 before link startup
@@ -546,7 +554,7 @@ static int ufs_mtk_link_set_hpm(struct ufs_hba *hba)
if (err)
return err;
- err = ufs_mtk_unipro_set_pm(hba, 0);
+ err = ufs_mtk_unipro_set_pm(hba, false);
if (err)
return err;
@@ -567,10 +575,10 @@ static int ufs_mtk_link_set_lpm(struct ufs_hba *hba)
{
int err;
- err = ufs_mtk_unipro_set_pm(hba, 1);
+ err = ufs_mtk_unipro_set_pm(hba, true);
if (err) {
/* Resume UniPro state for following error recovery */
- ufs_mtk_unipro_set_pm(hba, 0);
+ ufs_mtk_unipro_set_pm(hba, false);
return err;
}
--
2.18.0
[PATCH 0/4] scsi: ufs-mediatek: Fixes for kernel v5.10
Hi Martin, Avri, This series fix some defects and introduce host reset mechanism in MediaTek UFS platforms. Please consider this patch series for kernel v5.10. Thanks, Stanley Chu Stanley Chu (4): scsi: ufs-mediatek: Eliminate error message for unbound mphy scsi: ufs-mediatek: Fix HOST_PA_TACTIVATE quirk scsi: ufs-mediatek: Fix flag of unipro low-power mode scsi: ufs-mediatek: Add host reset mechanism drivers/scsi/ufs/ufs-mediatek.c | 79 ++--- drivers/scsi/ufs/ufs-mediatek.h | 3 ++ 2 files changed, 67 insertions(+), 15 deletions(-) -- 2.18.0
[PATCH 2/4] scsi: ufs-mediatek: Fix HOST_PA_TACTIVATE quirk
Simply add HOST_PA_TACTIVATE quirk back since it was incorrectly
removed before.
Fixes: 47d054580a75 ("scsi: ufs-mediatek: fix HOST_PA_TACTIVATE quirk for
Samsung UFS Devices")
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs-mediatek.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 7487b25fa651..887c03e8bcc0 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -672,13 +672,7 @@ static int ufs_mtk_apply_dev_quirks(struct ufs_hba *hba)
static void ufs_mtk_fixup_dev_quirks(struct ufs_hba *hba)
{
- struct ufs_dev_info *dev_info = >dev_info;
- u16 mid = dev_info->wmanufacturerid;
-
ufshcd_fixup_dev_quirks(hba, ufs_mtk_dev_fixups);
-
- if (mid == UFS_VENDOR_SAMSUNG)
- hba->dev_quirks &= ~UFS_DEVICE_QUIRK_HOST_PA_TACTIVATE;
}
/**
--
2.18.0
[PATCH 4/4] scsi: ufs-mediatek: Add host reset mechanism
Add host reset mechanism to try to recover host-side errors
during recovery flow.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs-mediatek.c | 48 +++--
drivers/scsi/ufs/ufs-mediatek.h | 3 +++
2 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index feba74a72309..1a9133ac6efb 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include "ufshcd.h"
@@ -91,16 +92,57 @@ static void ufs_mtk_crypto_enable(struct ufs_hba *hba)
}
}
+static void ufs_mtk_host_reset(struct ufs_hba *hba)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+
+ reset_control_assert(host->hci_reset);
+ reset_control_assert(host->crypto_reset);
+ reset_control_assert(host->unipro_reset);
+
+ usleep_range(100, 110);
+
+ reset_control_deassert(host->unipro_reset);
+ reset_control_deassert(host->crypto_reset);
+ reset_control_deassert(host->hci_reset);
+}
+
+static void ufs_mtk_init_reset_control(struct ufs_hba *hba,
+ struct reset_control **rc,
+ char *str)
+{
+ *rc = devm_reset_control_get(hba->dev, str);
+ if (IS_ERR(*rc)) {
+ dev_info(hba->dev, "Failed to get reset control %s: %d\n",
+str, PTR_ERR(*rc));
+ *rc = NULL;
+ }
+}
+
+static void ufs_mtk_init_reset(struct ufs_hba *hba)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+
+ ufs_mtk_init_reset_control(hba, >hci_reset,
+ "hci_rst");
+ ufs_mtk_init_reset_control(hba, >unipro_reset,
+ "unipro_rst");
+ ufs_mtk_init_reset_control(hba, >crypto_reset,
+ "crypto_rst");
+}
+
static int ufs_mtk_hce_enable_notify(struct ufs_hba *hba,
enum ufs_notify_change_status status)
{
struct ufs_mtk_host *host = ufshcd_get_variant(hba);
if (status == PRE_CHANGE) {
- if (host->unipro_lpm)
+ if (host->unipro_lpm) {
hba->vps->hba_enable_delay_us = 0;
- else
+ } else {
hba->vps->hba_enable_delay_us = 600;
+ ufs_mtk_host_reset(hba);
+ }
if (hba->caps & UFSHCD_CAP_CRYPTO)
ufs_mtk_crypto_enable(hba);
@@ -335,6 +377,8 @@ static int ufs_mtk_init(struct ufs_hba *hba)
if (err)
goto out_variant_clear;
+ ufs_mtk_init_reset(hba);
+
/* Enable runtime autosuspend */
hba->caps |= UFSHCD_CAP_RPM_AUTOSUSPEND;
diff --git a/drivers/scsi/ufs/ufs-mediatek.h b/drivers/scsi/ufs/ufs-mediatek.h
index 87657376d27a..5c32d5f52759 100644
--- a/drivers/scsi/ufs/ufs-mediatek.h
+++ b/drivers/scsi/ufs/ufs-mediatek.h
@@ -92,6 +92,9 @@ enum {
struct ufs_mtk_host {
struct ufs_hba *hba;
struct phy *mphy;
+ struct reset_control *hci_reset;
+ struct reset_control *unipro_reset;
+ struct reset_control *crypto_reset;
bool mphy_powered_on;
bool unipro_lpm;
bool ref_clk_enabled;
--
2.18.0
Re: [PATCH v2 3/4] qla2xxx: Drop unused function argument from qla2x00_get_sp_from_handle()
On Mon, 31 Aug 2020, 9:18am, Daniel Wagner wrote:
>
> Commit 7c3df1320e5e ("[SCSI] qla2xxx: Code changes to support new
> dynamic logging infrastructure.") removed the use of the func
> argument.
>
> Signed-off-by: Daniel Wagner
> ---
> drivers/scsi/qla2xxx/qla_gbl.h | 3 +--
> drivers/scsi/qla2xxx/qla_isr.c | 36
> drivers/scsi/qla2xxx/qla_mr.c | 9 +++--
> 3 files changed, 16 insertions(+), 32 deletions(-)
>
--8<--
> diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
> index 5d278155e4e7..b787643f5031 100644
> --- a/drivers/scsi/qla2xxx/qla_isr.c
> +++ b/drivers/scsi/qla2xxx/qla_isr.c
> @@ -1711,8 +1711,7 @@ qla2x00_process_completed_request(struct scsi_qla_host
> *vha,
> }
>
> srb_t *
> -qla2x00_get_sp_from_handle(scsi_qla_host_t *vha, const char *func,
> -struct req_que *req, void *iocb)
> +qla2x00_get_sp_from_handle(scsi_qla_host_t *vha, struct req_que *req, void
> *iocb)
> {
> struct qla_hw_data *ha = vha->hw;
> sts_entry_t *pkt = iocb;
How about printing the "func", which gives an indication of the caller
function, in the ql_log-s, rather than removing it? At least in the cases
like you describe, it'd give an indication which handler the path was
taken.
Regards,
-Arun
Re: [PATCH v2 4/4] qla2xxx: Handle incorrect entry_type entries
On Mon, 31 Aug 2020, 9:18am, Daniel Wagner wrote:
>
> It was observed on an ISP8324 16Gb HBA with fw=8.08.203 (d0d5) that
> pkt->entry_type was MBX_IOCB_TYPE/0x39 with an sp->type SRB_SCSI_CMD
> which is invalid and should not be possible.
>
> A careful code review of the crash dump didn't reveal any short
> comings. Reading the entry_type from the crash dump shows the expected
> value of STATUS_TYPE/0x03 but the call trace shows that
> qla24xx_mbx_iocb_entry() is used.
>
> One possible explanation is when pkt->entry_type is read it doesn't
> contain the correct information. That means the driver observes an data
> race by the firmware.
>
> Signed-off-by: Daniel Wagner
> ---
> drivers/scsi/qla2xxx/qla_isr.c | 30 --
> 1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
> index b787643f5031..22aa4c0b901d 100644
> --- a/drivers/scsi/qla2xxx/qla_isr.c
> +++ b/drivers/scsi/qla2xxx/qla_isr.c
> @@ -3392,6 +3392,33 @@ void qla24xx_nvme_ls4_iocb(struct scsi_qla_host *vha,
> sp->done(sp, comp_status);
> }
>
> +static void qla24xx_process_mbx_iocb_response(struct scsi_qla_host *vha,
> + struct rsp_que *rsp, struct sts_entry_24xx *pkt)
> +{
> + srb_t *sp;
> +
> + sp = qla2x00_get_sp_from_handle(vha, rsp->req, pkt);
> + if (!sp)
> + return;
> +
> + if (sp->type == SRB_SCSI_CMD ||
> + sp->type == SRB_NVME_CMD ||
> + sp->type == SRB_TM_CMD) {
> + /* Some firmware version don't update the entry_type
> + * correctly. It was observed entry_type contained
> + * MBCX_IOCB_TYPE instead of the expected STATUS_TYPE
> + * for sp->type SRB_SCSI_CMD, SRB_NVME_CMD or
> + * SRB_TM_CMD.
> + */
Could you drop the above comment about firmware, as it is speculation at
this point?
> + ql_log(ql_log_warn, vha, 0x509d,
> +"Firmware didn't update entry_type correctly\n");
> + qla2x00_status_entry(vha, rsp, pkt);
> + return;
It'd be best to take a chip reset path, rather than assuming the
packet is good and having the appropriate handler called (hacky).
An approach similar to the one done at the beginning of
qla2x00_get_sp_from_handle() is what I had in mind.
> + }
> +
> + qla24xx_mbx_iocb_entry(vha, rsp->req, (struct mbx_24xx_entry *)pkt);
> +}
> +
> /**
> * qla24xx_process_response_queue() - Process response queue entries.
> * @vha: SCSI driver HA context
> @@ -3499,8 +3526,7 @@ void qla24xx_process_response_queue(struct
> scsi_qla_host *vha,
> (struct abort_entry_24xx *)pkt);
> break;
> case MBX_IOCB_TYPE:
> - qla24xx_mbx_iocb_entry(vha, rsp->req,
> - (struct mbx_24xx_entry *)pkt);
> + qla24xx_process_mbx_iocb_response(vha, rsp, pkt);
I'd have preferred a common approach across the different IOCB types
as an attempt to harden the code, but that will be a little more
involved work. This looks ok.
Regards,
-Arun
[PATCH] drm/virtio: drop quirks handling
These days dma ops can be overridden per device, and the virtio core
uses that to handle the dma quirks transparently for the rest of the
kernel. So we can drop the virtio_has_dma_quirk() checks, just use
the dma api unconditionally and depend on the virtio core having setup
dma_ops as needed.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_object.c | 19 ++-
drivers/gpu/drm/virtio/virtgpu_vq.c | 16 ++--
2 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 729f98ad7c02..9c35ce64ff9e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -141,7 +141,6 @@ static int virtio_gpu_object_shmem_init(struct
virtio_gpu_device *vgdev,
struct virtio_gpu_mem_entry **ents,
unsigned int *nents)
{
- bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev);
struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo);
struct scatterlist *sg;
int si, ret;
@@ -162,15 +161,11 @@ static int virtio_gpu_object_shmem_init(struct
virtio_gpu_device *vgdev,
return -EINVAL;
}
- if (use_dma_api) {
- shmem->mapped = dma_map_sg(vgdev->vdev->dev.parent,
- shmem->pages->sgl,
- shmem->pages->nents,
- DMA_TO_DEVICE);
- *nents = shmem->mapped;
- } else {
- *nents = shmem->pages->nents;
- }
+ shmem->mapped = dma_map_sg(vgdev->vdev->dev.parent,
+ shmem->pages->sgl,
+ shmem->pages->nents,
+ DMA_TO_DEVICE);
+ *nents = shmem->mapped;
*ents = kmalloc_array(*nents, sizeof(struct virtio_gpu_mem_entry),
GFP_KERNEL);
@@ -180,9 +175,7 @@ static int virtio_gpu_object_shmem_init(struct
virtio_gpu_device *vgdev,
}
for_each_sg(shmem->pages->sgl, sg, *nents, si) {
- (*ents)[si].addr = cpu_to_le64(use_dma_api
- ? sg_dma_address(sg)
- : sg_phys(sg));
+ (*ents)[si].addr = cpu_to_le64(sg_dma_address(sg));
(*ents)[si].length = cpu_to_le32(sg->length);
(*ents)[si].padding = 0;
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index c93c2db35aaf..1c1d2834547d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -599,13 +599,11 @@ void virtio_gpu_cmd_transfer_to_host_2d(struct
virtio_gpu_device *vgdev,
struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(objs->objs[0]);
struct virtio_gpu_transfer_to_host_2d *cmd_p;
struct virtio_gpu_vbuffer *vbuf;
- bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev);
struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo);
- if (use_dma_api)
- dma_sync_sg_for_device(vgdev->vdev->dev.parent,
- shmem->pages->sgl, shmem->pages->nents,
- DMA_TO_DEVICE);
+ dma_sync_sg_for_device(vgdev->vdev->dev.parent,
+ shmem->pages->sgl, shmem->pages->nents,
+ DMA_TO_DEVICE);
cmd_p = virtio_gpu_alloc_cmd(vgdev, , sizeof(*cmd_p));
memset(cmd_p, 0, sizeof(*cmd_p));
@@ -1015,13 +1013,11 @@ void virtio_gpu_cmd_transfer_to_host_3d(struct
virtio_gpu_device *vgdev,
struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(objs->objs[0]);
struct virtio_gpu_transfer_host_3d *cmd_p;
struct virtio_gpu_vbuffer *vbuf;
- bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev);
struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo);
- if (use_dma_api)
- dma_sync_sg_for_device(vgdev->vdev->dev.parent,
- shmem->pages->sgl, shmem->pages->nents,
- DMA_TO_DEVICE);
+ dma_sync_sg_for_device(vgdev->vdev->dev.parent,
+ shmem->pages->sgl, shmem->pages->nents,
+ DMA_TO_DEVICE);
cmd_p = virtio_gpu_alloc_cmd(vgdev, , sizeof(*cmd_p));
memset(cmd_p, 0, sizeof(*cmd_p));
--
2.27.0
Re: [PATCH 03/25] dt-bindings: iio: adc: exynos-adc: do not require syscon on S5Pv210
On Mon, Sep 07, 2020 at 02:49:49PM -0700, Jonathan Bakker wrote: > Looking at this again, it appears that there is actually control for > it at offset 0x6818 of pmu_syscon (0xe0108000) [1]. However, it defaults to > enabled so it's not required for proper use of the block. Whether it should > be present in the schema/DTS is up to you. Indeed the driver could turn off the ADC phy via syscon however bindings (before YAML conversion) explicitly were saying that it is not needed. I am not going to add it as I am not able to test the change and also adding such requirement would be a break of ABI (described by first TXT bindings). Best regards, Krzysztof > > Thanks, > Jonathan > > [1] > https://android.googlesource.com/kernel/samsung/+/refs/heads/android-samsung-3.0-jb-mr0/arch/arm/mach-s5pv210/include/mach/regs-clock.h#325 > > On 2020-09-07 9:11 a.m., Krzysztof Kozlowski wrote: > > The ADC in S5Pv210 does not have ADC phy registers in separate block for > > which syscon would be needed. Remove this requirement to fix dtbs_check > > warnings like: > > > > arch/arm/boot/dts/s5pv210-fascinate4g.dt.yaml: adc@e170: > > 'samsung,syscon-phandle' is a required property > > > > Signed-off-by: Krzysztof Kozlowski > > --- > > .../devicetree/bindings/iio/adc/samsung,exynos-adc.yaml | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git > > a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml > > b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml > > index 89b4f9c252a6..75174af72288 100644 > > --- a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml > > +++ b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml > > @@ -81,7 +81,6 @@ allOf: > >- samsung,exynos-adc-v2 > >- samsung,exynos3250-adc > >- samsung,exynos4212-adc > > - - samsung,s5pv210-adc > > then: > >required: > > - samsung,syscon-phandle > >
Re: [PATCH v6 04/13] usb: dwc3: Add splitdisable quirk for Hisilicon Kirin Soc
Em Tue, 08 Sep 2020 09:09:46 +0300 Felipe Balbi escreveu: > >> Why does it affect only Hikey kirin? > > > > As John Stultz didn't re-submit this one (and looking at the DT > > between Kirin 960 and 970 from the original Kernel 4.9 official > > drivers), I suspect that only Kirin 970 requires this quirk. > > > > It could well be due to some Dwc3 revision, but it could also be due > > to some differences at the USB part of the SoC, as there are a > > the reason I ask is that if it's caused by dwc3 revision, then we don't > need the extra dt property, we can rely on a revision check. If it's > something that can't be detected in runtime, then we need a property. Yeah, if it would be possible to auto-detect, that would be better. Yet, hard to say if it would be possible to do that, without access to the Dwc3 docs, and without different hardware for testing it. > > few other things different between hikey 960 and 970: it has a > > different PHY driver, and there are also some differences at the > > USB HUB which is connected into it. > > > > On both devices, the USB physical ports are actually connected > > into a HUB. In the case of Hikey 970, the hub seems to be a > > TI TUSB8041 4-Port Hub: > > > > $ lsusb > > Bus 002 Device 002: ID 0451:8140 Texas Instruments, Inc. TUSB8041 > > 4-Port Hub > > Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > > Bus 001 Device 004: ID 090c:1000 Silicon Motion, Inc. - Taiwan > > (formerly Feiya Technology Corp.) Flash Drive > > Bus 001 Device 003: ID 413c:301a Dell Computer Corp. Dell MS116 Optical > > Mouse > > Bus 001 Device 002: ID 0451:8142 Texas Instruments, Inc. TUSB8041 > > 4-Port Hub > > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > > >> What's the dwc3 revision on > >> that SoC (grep SNPSID /sys/kernel/debugfs/*dwc3/regdump)? > > > > GSNPSID = 0x33313130 > > This isn't even listed as a known revision in dwc3/core.h. Thinh, could > the issue being described here caused by a known Erratum with this > particular revision? Maybe. Again, hard to tell without any documentation from Synopsys. Maybe some of the Synopsys folks at USB MK can shed a light. Thanks, Mauro
Re: [PATCH v2 10/11] dwc3-of-simple: add support for Hikey 970
Em Mon, 7 Sep 2020 17:59:34 +0200 Mauro Carvalho Chehab escreveu: > diff --git a/drivers/usb/dwc3/dwc3-of-simple.c > b/drivers/usb/dwc3/dwc3-of-simple.c > index 8852fbfdead4..2d497165efe2 100644 > --- a/drivers/usb/dwc3/dwc3-of-simple.c > +++ b/drivers/usb/dwc3/dwc3-of-simple.c > @@ -49,7 +49,8 @@ static int dwc3_of_simple_probe(struct platform_device > *pdev) >* Some controllers need to toggle the usb3-otg reset before trying to >* initialize the PHY, otherwise the PHY times out. >*/ > - if (of_device_is_compatible(np, "rockchip,rk3399-dwc3")) > + if (of_device_is_compatible(np, "rockchip,rk3399-dwc3") || > + of_device_is_compatible(np, "hisilicon,hi3670-dwc3")) > simple->need_reset = true; It turns that this hunk caused Serror during my suspend/resume tests. Without this one, the driver works just fine. As you already applied this patch, do you prefer a patch dropping it, or should I send a version 2 without it? Thanks, Mauro
Re: [RFT 09/25] ARM: dts: s5pv210: fix number of I2S DAI cells
On Mon, Sep 07, 2020 at 04:55:26PM -0700, Jonathan Bakker wrote:
> Sadly, this is causing issues for me. The machine driver is no longer
> probing correctly
> on the Galaxy S.
>
> The failing call in sound/soc/samsung/aries_wm8994.c is
>
> /* Set CPU of_node for BT DAI */
> aries_dai[2].cpus->of_node = of_parse_phandle(cpu,
> "sound-dai", 1);
>
> where cpus->of_node is not set properly. Which is definitely weird because
> it doesn't
> look like this should affect that.
>
> Let me know if there's any specific test that you want me to do.
Thanks for the tests. I wonder now if this was working before because
really my change should not break it... I'll think more about it.
Best regards,
Krzysztof
>
> Thanks,
> Jonathan
>
>
> On 2020-09-07 9:11 a.m., Krzysztof Kozlowski wrote:
> > The bindings describe I2S DAI has 1 cells. This makes especially sense
> > for i2s0 which registers two DAIs. Adjust the cells to fix dtbs_check
> > warnings like:
> >
> > i2s@e210: #sound-dai-cells:0:0: 1 was expected
> >
> > Signed-off-by: Krzysztof Kozlowski
> > ---
> > arch/arm/boot/dts/s5pv210-fascinate4g.dts | 2 +-
> > arch/arm/boot/dts/s5pv210-galaxys.dts | 2 +-
> > arch/arm/boot/dts/s5pv210.dtsi| 6 +++---
> > 3 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/s5pv210-fascinate4g.dts
> > b/arch/arm/boot/dts/s5pv210-fascinate4g.dts
> > index ca064359dd30..a6dc8a173af1 100644
> > --- a/arch/arm/boot/dts/s5pv210-fascinate4g.dts
> > +++ b/arch/arm/boot/dts/s5pv210-fascinate4g.dts
> > @@ -102,7 +102,7 @@
> > pinctrl-0 = <_det _sel>;
> >
> > cpu {
> > - sound-dai = <>, <_codec>;
> > + sound-dai = < 0>, <_codec>;
> > };
> >
> > codec {
> > diff --git a/arch/arm/boot/dts/s5pv210-galaxys.dts
> > b/arch/arm/boot/dts/s5pv210-galaxys.dts
> > index 560f830b6f6b..0eba06f56ac7 100644
> > --- a/arch/arm/boot/dts/s5pv210-galaxys.dts
> > +++ b/arch/arm/boot/dts/s5pv210-galaxys.dts
> > @@ -132,7 +132,7 @@
> > pinctrl-0 = <_det _sel>;
> >
> > cpu {
> > - sound-dai = <>, <_codec>;
> > + sound-dai = < 0>, <_codec>;
> > };
> >
> > codec {
> > diff --git a/arch/arm/boot/dts/s5pv210.dtsi b/arch/arm/boot/dts/s5pv210.dtsi
> > index 2871351ab907..96e667ba1c3f 100644
> > --- a/arch/arm/boot/dts/s5pv210.dtsi
> > +++ b/arch/arm/boot/dts/s5pv210.dtsi
> > @@ -251,7 +251,7 @@
> > samsung,idma-addr = <0xc001>;
> > pinctrl-names = "default";
> > pinctrl-0 = <_bus>;
> > - #sound-dai-cells = <0>;
> > + #sound-dai-cells = <1>;
> > status = "disabled";
> > };
> >
> > @@ -266,7 +266,7 @@
> > clocks = < CLK_I2S1>, < SCLK_AUDIO1>;
> > pinctrl-names = "default";
> > pinctrl-0 = <_bus>;
> > - #sound-dai-cells = <0>;
> > + #sound-dai-cells = <1>;
> > status = "disabled";
> > };
> >
> > @@ -281,7 +281,7 @@
> > clocks = < CLK_I2S2>, < SCLK_AUDIO2>;
> > pinctrl-names = "default";
> > pinctrl-0 = <_bus>;
> > - #sound-dai-cells = <0>;
> > + #sound-dai-cells = <1>;
> > status = "disabled";
> > };
> >
> >
Re: [PATCH 11/25] ARM: dts: s5pv210: add RTC 32 KHz clock in Aries family
On Mon, Sep 07, 2020 at 04:57:53PM -0700, Jonathan Bakker wrote:
> Hi Krzysztof,
>
> On 2020-09-07 9:11 a.m., Krzysztof Kozlowski wrote:
> > The S3C RTC requires 32768 Hz clock as input which is provided by PMIC.
> > However there is no such clock provider but rather a regulator driver
> > which registers the clock as a regulator. This is an old driver which
> > will not be updated so add a workaround - a fixed-clock to fill missing
> > clock phandle reference in S3C RTC.
> >
> > This fixes dtbs_check warnings:
> >
> > rtc@e280: clocks: [[2, 145]] is too short
> > rtc@e280: clock-names: ['rtc'] is too short
> >
> > Signed-off-by: Krzysztof Kozlowski
> > ---
> > arch/arm/boot/dts/s5pv210-aries.dtsi | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/s5pv210-aries.dtsi
> > b/arch/arm/boot/dts/s5pv210-aries.dtsi
> > index 6ba23562da46..86c3b26fd21e 100644
> > --- a/arch/arm/boot/dts/s5pv210-aries.dtsi
> > +++ b/arch/arm/boot/dts/s5pv210-aries.dtsi
> > @@ -47,6 +47,13 @@
> > };
> > };
> >
> > + pmic_ap_clk: clock-0 {
> > + /* Workaround for missing clock on PMIC */
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <32768>;
> > + };
> > +
> > bt_codec: bt_sco {
> > compatible = "linux,bt-sco";
> > #sound-dai-cells = <0>;
> > @@ -825,6 +832,11 @@
> > samsung,pwm-outputs = <1>;
> > };
> >
> > + {
> > + clocks = < CLK_RTC>, <_ap_clk>;
> > + clock-names = "rtc", "rtc_src";
>
> Missing a
>
> status = "okay";
>
> here, but with that it works fine for me. Looks like it's also
> missing in the patches for the other devices as well.
It wasn't there on purpose - I did not want to enable the RTC, just fix
the DTS with the dtschema. However a separate patch could be to actually
enable it.
I'll add your tested-by to this patch.
Best regards,
Krzysztof
Re: [PATCH v11 0/2] s390: virtio: let arch validate VIRTIO features
On Tue, 8 Sep 2020 00:39:51 +0200 Halil Pasic wrote: > On Mon, 7 Sep 2020 11:39:05 +0200 > Pierre Morel wrote: > > > Hi all, > > > > The goal of the series is to give a chance to the architecture > > to validate VIRTIO device features. > > Michael, is this going in via your tree? > I believe Michael's tree is the right place for this, but I can also queue it if I get an ack on patch 1.
Re: [PATCH] mm: check for memory's node later during boot
Le 03/09/2020 à 23:35, Andrew Morton a écrit : On Wed, 2 Sep 2020 11:09:11 +0200 Laurent Dufour wrote: register_mem_sect_under_nodem() is checking the memory block's node id only if the system state is "SYSTEM_BOOTING". On PowerPC, the memory blocks are registered while the system state is "SYSTEM_SCHEDULING", the one before SYSTEM_RUNNING. The consequence on PowerPC guest with interleaved memory node's ranges is that some memory block could be assigned to multiple nodes on sysfs. This lately prevents some memory hot-plug and hot-unplug to succeed because links are remaining. Such a panic is then displayed: [ cut here ] kernel BUG at /Users/laurent/src/linux-ppc/mm/memory_hotplug.c:1084! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: rpadlpar_io rpaphp pseries_rng rng_core vmx_crypto gf128mul binfmt_misc ip_tables x_tables xfs libcrc32c crc32c_vpmsum autofs4 CPU: 8 PID: 10256 Comm: drmgr Not tainted 5.9.0-rc1+ #25 NIP: c0403f34 LR: c0403f2c CTR: REGS: c004876e3660 TRAP: 0700 Not tainted (5.9.0-rc1+) MSR: 8282b033 CR: 24000448 XER: 2004 CFAR: c0846d20 IRQMASK: 0 GPR00: c0403f2c c004876e38f0 c12f6f00 ffef GPR04: 0227 c004805ae680 0004886f GPR08: 0226 0003 0002 fffd GPR12: 88000484 c0001ec96280 GPR16: 0004 0003 GPR20: c0047814ffe0 c0077c08 0010 c13332c8 GPR24: c11f6cc0 GPR28: ffef 0001 00015000 1000 NIP [c0403f34] add_memory_resource+0x244/0x340 LR [c0403f2c] add_memory_resource+0x23c/0x340 Call Trace: [c004876e38f0] [c0403f2c] add_memory_resource+0x23c/0x340 (unreliable) [c004876e39c0] [c040408c] __add_memory+0x5c/0xf0 [c004876e39f0] [c00e2b94] dlpar_add_lmb+0x1b4/0x500 [c004876e3ad0] [c00e3888] dlpar_memory+0x1f8/0xb80 [c004876e3b60] [c00dc0d0] handle_dlpar_errorlog+0xc0/0x190 [c004876e3bd0] [c00dc398] dlpar_store+0x198/0x4a0 [c004876e3c90] [c072e630] kobj_attr_store+0x30/0x50 [c004876e3cb0] [c051f954] sysfs_kf_write+0x64/0x90 [c004876e3cd0] [c051ee40] kernfs_fop_write+0x1b0/0x290 [c004876e3d20] [c0438dd8] vfs_write+0xe8/0x290 [c004876e3d70] [c04391ac] ksys_write+0xdc/0x130 [c004876e3dc0] [c0034e40] system_call_exception+0x160/0x270 [c004876e3e20] [c000d740] system_call_common+0xf0/0x27c Instruction dump: 48442e35 6000 0b03 3cbe0001 7fa3eb78 7bc48402 38a5fffe 7ca5fa14 78a58402 48442db1 6000 7c7c1b78 <0b03> 7f23cb78 4bda371d 6000 ---[ end trace 562fd6c109cd0fb2 ]--- To prevent this multiple links, make the node checking done for states prior to SYSTEM_RUNNING. Did you consider adding a cc:stable to this fix? I should have, but now I've to review the fix based on David's comment.
Re: [RFT 25/25] ARM: dts: s5pv210: align DMA channels with dtschema
On Mon, Sep 07, 2020 at 05:28:54PM -0700, Jonathan Bakker wrote: > Ah, I figured out why the dma stopped working. In s5pv210-aries.dtsi the > dma's for i2s0 > are overriden to use pdma0 instead of pdma1. That also needs changing for > this to > work properly. Indeed I missed this, thanks for review and tests. Best regards, Krzysztof > > Thanks, > Jonathan > > On 2020-09-07 5:17 p.m., Jonathan Bakker wrote: > > Initial testing on both an i9000 and an SGH-T959P are showing that the > > audio has > > stopped working with this. I'm not 100% convinced as I've had DMA issues > > in the > > past. However trying to play something just results in a hang after 1.5s > > while > > it works just fine without this patch. > > > > Thanks, > > Jonathan
Re: [PATCHv3] selftests: rtnetlink: load fou module for kci_test_encap_fou() test
On Tue, Sep 8, 2020 at 4:12 AM Jakub Kicinski wrote: > > On Mon, 7 Sep 2020 11:50:10 +0800 Po-Hsu Lin wrote: > > The kci_test_encap_fou() test from kci_test_encap() in rtnetlink.sh > > needs the fou module to work. Otherwise it will fail with: > > > > $ ip netns exec "$testns" ip fou add port ipproto 47 > > RTNETLINK answers: No such file or directory > > Error talking to the kernel > > > > Add the CONFIG_NET_FOU into the config file as well. Which needs at > > least to be set as a loadable module. > > > > Signed-off-by: Po-Hsu Lin > > > diff --git a/tools/testing/selftests/net/rtnetlink.sh > > b/tools/testing/selftests/net/rtnetlink.sh > > index 7c38a90..a711b3e 100755 > > --- a/tools/testing/selftests/net/rtnetlink.sh > > +++ b/tools/testing/selftests/net/rtnetlink.sh > > @@ -520,6 +520,11 @@ kci_test_encap_fou() > > return $ksft_skip > > fi > > > > + if ! /sbin/modprobe -q -n fou; then > > + echo "SKIP: module fou is not found" > > + return $ksft_skip > > + fi > > + /sbin/modprobe -q fou > > ip -netns "$testns" fou add port ipproto 47 2>/dev/null > > if [ $? -ne 0 ];then > > echo "FAIL: can't add fou port , skipping test" > > @@ -540,6 +545,7 @@ kci_test_encap_fou() > > return 1 > > fi > > > > + /sbin/modprobe -q -r fou > > I think the common practice is to not remove the module at the end of > the test. It may be used by something else than the test itself. > Hello Jakub, Thanks for your feedback. For this case I think it's safe to remove the module here, as it was never loaded before and thus causing this test to fail. If other tests in this rtnetlink.sh need this fou module, we should be able to spot those failures too, however this is the only failure as I can see. (pmtu.sh will need fou module to run as well, but it will be loaded there.) Shouldn't we insert the required module whenever the test needs it? So that we can run the test itself directly, without depending on other tests. Also, I can see modules for tests were being unloaded in other tests as well. Thanks > > echo "PASS: fou" > > } > > >
Re: [EXT] Re: [PATCH] MAINTAINERS: orphan sections with qlogic.com group alias
On Fri, 28 Aug 2020, 8:39am, Martin K. Petersen wrote: > > Lukas, > > > So, if these drivers are not orphans, you can answer Thomas Gleixner's > > original email from 2019. If you can quickly ack that patch set, I am > > happy to do the donkey work to get this apply nicely on the current > > master (please CC me on that response). > > This is the first I hear of this since the patches weren't CC:ed to > linux-scsi. And not all of these changes pertain to storage drivers but > to networking so I am also not sure that mails sent to the above Storage > alias would have ended up in the right place. > > But we'll get this fixed up. Reaching out to our contacts at Marvell. > Just to keep this thread updated, we are checking with the legal before ack-ing the change on spdx. Nilesh has already updated Thomas G. about this on the orignal spdx thread. Regards, -Arun PS: Thanks Roman for the CC. These days our spam filters are a little unfriendly towards the linux-* e-mails.
Re: [PATCH v2] kbuild: preprocess module linker script
On Tue, Sep 8, 2020 at 6:29 AM Masahiro Yamada wrote:
> There was a request to preprocess the module linker script like we
> do for the vmlinux one. (https://lkml.org/lkml/2020/8/21/512)
>
> The difference between vmlinux.lds and module.lds is that the latter
> is needed for external module builds, thus must be cleaned up by
> 'make mrproper' instead of 'make clean'. Also, it must be created
> by 'make modules_prepare'.
>
> You cannot put it in arch/$(SRCARCH)/kernel/, which is cleaned up by
> 'make clean'. I moved arch/$(SRCARCH)/kernel/module.lds to
> arch/$(SRCARCH)/include/asm/module.lds.h, which is included from
> scripts/module.lds.S.
>
> scripts/module.lds is fine because 'make clean' keeps all the
> build artifacts under scripts/.
>
> You can add arch-specific sections in .
>
> Signed-off-by: Masahiro Yamada
> Tested-by: Jessica Yu
> Acked-by: Will Deacon
> arch/m68k/Makefile | 1 -
> .../{kernel/module.lds => include/asm/module.lds.h}| 0
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 1/1] i2c: algo-pca: Reapply i2c bus settings after reset
Hi Evan,
> changes in v2:
> - changed lowercase "pca to uppercase "PCA".
> - reworded and reformatted the multiline comment.
> - moved the clock frequency KERN_INFO closer to the call that sets this.
> - moved the i2c_bus_settings struct to the more generic i2c.h and removed
> - the comments indicating this as being for the pca chip.
As mentioned in v1, I think we should not have it in the generic i2c
headers yet. a) it makes backporting more difficult and b) we need to
find the optimal generic set of parameters which is a seperate issue.
>
> - pca_reset(pca_data);
> -
> clock = pca_clock(pca_data);
> +
> printk(KERN_INFO "%s: Clock frequency is %dkHz\n",
>adap->name, freqs[clock]);
Minor nit: I think there is no need for the extra blank line, but I'll
let you decide.
> +/**
> + * struct i2c_bus_settings - The configured i2c bus settings
> + * @mode: Configured i2c bus mode
> + * @tlow: Configured SCL LOW period
> + * @thi: Configured SCL HIGH period
> + * @clock_freq: The configured clock frequency
> + */
> +struct i2c_bus_settings {
'pca_i2c_bus_settings' or similar?
Rest looks good!
Thanks,
Wolfram
signature.asc
Description: PGP signature
[PATCH 1/3] drm/virtio: use drmm_mode_config_init
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
drivers/gpu/drm/virtio/virtgpu_display.c | 11 +++
drivers/gpu/drm/virtio/virtgpu_kms.c | 6 +-
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index a52b7a39f286..55c34b4fc3e9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -352,7 +352,7 @@ virtio_gpu_cmd_resource_assign_uuid(struct
virtio_gpu_device *vgdev,
struct virtio_gpu_object_array *objs);
/* virtgpu_display.c */
-void virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev);
+int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev);
void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev);
/* virtgpu_plane.c */
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index effea07abe62..f84b7e61311b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -325,11 +325,14 @@ static const struct drm_mode_config_funcs
virtio_gpu_mode_funcs = {
.atomic_commit = drm_atomic_helper_commit,
};
-void virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev)
+int virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev)
{
- int i;
+ int i, ret;
+
+ ret = drmm_mode_config_init(vgdev->ddev);
+ if (ret)
+ return ret;
- drm_mode_config_init(vgdev->ddev);
vgdev->ddev->mode_config.quirk_addfb_prefer_host_byte_order = true;
vgdev->ddev->mode_config.funcs = _gpu_mode_funcs;
@@ -343,6 +346,7 @@ void virtio_gpu_modeset_init(struct virtio_gpu_device
*vgdev)
vgdev_output_init(vgdev, i);
drm_mode_config_reset(vgdev->ddev);
+ return 0;
}
void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev)
@@ -351,5 +355,4 @@ void virtio_gpu_modeset_fini(struct virtio_gpu_device
*vgdev)
for (i = 0 ; i < vgdev->num_scanouts; ++i)
kfree(vgdev->outputs[i].edid);
- drm_mode_config_cleanup(vgdev->ddev);
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 75d0dc2f6d28..6ea74a99d8ad 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -184,7 +184,11 @@ int virtio_gpu_init(struct drm_device *dev)
num_capsets, _capsets);
DRM_INFO("number of cap sets: %d\n", num_capsets);
- virtio_gpu_modeset_init(vgdev);
+ ret = virtio_gpu_modeset_init(vgdev);
+ if (ret) {
+ DRM_ERROR("modeset init failed\n");
+ goto err_scanouts;
+ }
virtio_device_ready(vgdev->vdev);
--
2.27.0
[PATCH 2/3] drm/virtio: return virtio_gpu_queue errors
In case queuing virtio commands fails (can happen when
the device got unplugged) pass up the error.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 36 +++--
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index c93c2db35aaf..b1884e6e242c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -320,13 +320,13 @@ static struct sg_table *vmalloc_to_sgt(char *data,
uint32_t size, int *sg_ents)
return sgt;
}
-static void virtio_gpu_queue_ctrl_sgs(struct virtio_gpu_device *vgdev,
- struct virtio_gpu_vbuffer *vbuf,
- struct virtio_gpu_fence *fence,
- int elemcnt,
- struct scatterlist **sgs,
- int outcnt,
- int incnt)
+static int virtio_gpu_queue_ctrl_sgs(struct virtio_gpu_device *vgdev,
+struct virtio_gpu_vbuffer *vbuf,
+struct virtio_gpu_fence *fence,
+int elemcnt,
+struct scatterlist **sgs,
+int outcnt,
+int incnt)
{
struct virtqueue *vq = vgdev->ctrlq.vq;
int ret, idx;
@@ -335,7 +335,7 @@ static void virtio_gpu_queue_ctrl_sgs(struct
virtio_gpu_device *vgdev,
if (fence && vbuf->objs)
virtio_gpu_array_unlock_resv(vbuf->objs);
free_vbuf(vgdev, vbuf);
- return;
+ return -1;
}
if (vgdev->has_indirect)
@@ -373,15 +373,16 @@ static void virtio_gpu_queue_ctrl_sgs(struct
virtio_gpu_device *vgdev,
spin_unlock(>ctrlq.qlock);
drm_dev_exit(idx);
+ return 0;
}
-static void virtio_gpu_queue_fenced_ctrl_buffer(struct virtio_gpu_device
*vgdev,
- struct virtio_gpu_vbuffer *vbuf,
- struct virtio_gpu_fence *fence)
+static int virtio_gpu_queue_fenced_ctrl_buffer(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_vbuffer *vbuf,
+ struct virtio_gpu_fence *fence)
{
struct scatterlist *sgs[3], vcmd, vout, vresp;
struct sg_table *sgt = NULL;
- int elemcnt = 0, outcnt = 0, incnt = 0;
+ int elemcnt = 0, outcnt = 0, incnt = 0, ret;
/* set up vcmd */
sg_init_one(, vbuf->buf, vbuf->size);
@@ -398,7 +399,7 @@ static void virtio_gpu_queue_fenced_ctrl_buffer(struct
virtio_gpu_device *vgdev,
if (!sgt) {
if (fence && vbuf->objs)
virtio_gpu_array_unlock_resv(vbuf->objs);
- return;
+ return -1;
}
elemcnt += sg_ents;
@@ -419,13 +420,14 @@ static void virtio_gpu_queue_fenced_ctrl_buffer(struct
virtio_gpu_device *vgdev,
incnt++;
}
- virtio_gpu_queue_ctrl_sgs(vgdev, vbuf, fence, elemcnt, sgs, outcnt,
- incnt);
+ ret = virtio_gpu_queue_ctrl_sgs(vgdev, vbuf, fence, elemcnt, sgs,
outcnt,
+ incnt);
if (sgt) {
sg_free_table(sgt);
kfree(sgt);
}
+ return ret;
}
void virtio_gpu_notify(struct virtio_gpu_device *vgdev)
@@ -444,10 +446,10 @@ void virtio_gpu_notify(struct virtio_gpu_device *vgdev)
virtqueue_notify(vgdev->ctrlq.vq);
}
-static void virtio_gpu_queue_ctrl_buffer(struct virtio_gpu_device *vgdev,
+static int virtio_gpu_queue_ctrl_buffer(struct virtio_gpu_device *vgdev,
struct virtio_gpu_vbuffer *vbuf)
{
- virtio_gpu_queue_fenced_ctrl_buffer(vgdev, vbuf, NULL);
+ return virtio_gpu_queue_fenced_ctrl_buffer(vgdev, vbuf, NULL);
}
static void virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
--
2.27.0
[PATCH 3/3] drm/virtio: add virtio_gpu_cmd_unref_resource error handling
Usually we wait for the host to complete the unref request, then cleanup
the guest-side state of the object in the completion callback. When
submitting the unref command failed the completion callback will not be
called though, so cleanup right away.
Fixes a WARN on stale mm entries on driver shutdown.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index b1884e6e242c..4d2325bf4aed 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -536,6 +536,7 @@ void virtio_gpu_cmd_unref_resource(struct virtio_gpu_device
*vgdev,
{
struct virtio_gpu_resource_unref *cmd_p;
struct virtio_gpu_vbuffer *vbuf;
+ int ret;
cmd_p = virtio_gpu_alloc_cmd_cb(vgdev, , sizeof(*cmd_p),
virtio_gpu_cmd_unref_cb);
@@ -545,7 +546,9 @@ void virtio_gpu_cmd_unref_resource(struct virtio_gpu_device
*vgdev,
cmd_p->resource_id = cpu_to_le32(bo->hw_res_handle);
vbuf->resp_cb_data = bo;
- virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
+ ret = virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
+ if (ret < 0)
+ virtio_gpu_cleanup_object(bo);
}
void virtio_gpu_cmd_set_scanout(struct virtio_gpu_device *vgdev,
--
2.27.0
[PATCH v2 3/3] dt-bindings: dw-apb-ictl: support hierarchy irq domain
Add support to use dw-apb-ictl as primary interrupt controller.
Signed-off-by: Zhen Lei
---
.../interrupt-controller/snps,dw-apb-ictl.txt | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
index 086ff08322db..2db59df9408f 100644
---
a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
+++
b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
@@ -2,7 +2,8 @@ Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
Synopsys DesignWare provides interrupt controller IP for APB known as
dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs with
-APB bus, e.g. Marvell Armada 1500.
+APB bus, e.g. Marvell Armada 1500. It can also be used as primary interrupt
+controller in some SoCs, e.g. Hisilicon SD5203.
Required properties:
- compatible: shall be "snps,dw-apb-ictl"
@@ -10,6 +11,8 @@ Required properties:
region starting with ENABLE_LOW register
- interrupt-controller: identifies the node as an interrupt controller
- #interrupt-cells: number of cells to encode an interrupt-specifier, shall be
1
+
+Additional required property when it's used as secondary interrupt controller:
- interrupts: interrupt reference to primary interrupt controller
The interrupt sources map to the corresponding bits in the interrupt
@@ -21,6 +24,7 @@ registers, i.e.
- (optional) fast interrupts start at 64.
Example:
+ /* dw_apb_ictl is used as secondary interrupt controller */
aic: interrupt-controller@3000 {
compatible = "snps,dw-apb-ictl";
reg = <0x3000 0xc00>;
@@ -29,3 +33,11 @@ Example:
interrupt-parent = <>;
interrupts = ;
};
+
+ /* dw_apb_ictl is used as primary interrupt controller */
+ vic: interrupt-controller@1013 {
+ compatible = "snps,dw-apb-ictl";
+ reg = <0x1013 0x1000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
--
2.26.0.106.g9fadedd
[PATCH v2 2/3] irqchip: dw-apb-ictl: support hierarchy irq domain
Add support to use dw-apb-ictl as primary interrupt controller.
Suggested-by: Marc Zyngier
Signed-off-by: Zhen Lei
Tested-by: Haoyu Lv
---
drivers/irqchip/Kconfig | 2 +-
drivers/irqchip/irq-dw-apb-ictl.c | 75 +--
2 files changed, 73 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index bfc9719dbcdc..7c2d1c8fa551 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -148,7 +148,7 @@ config DAVINCI_CP_INTC
config DW_APB_ICTL
bool
select GENERIC_IRQ_CHIP
- select IRQ_DOMAIN
+ select IRQ_DOMAIN_HIERARCHY
config FARADAY_FTINTC010
bool
diff --git a/drivers/irqchip/irq-dw-apb-ictl.c
b/drivers/irqchip/irq-dw-apb-ictl.c
index aa6214da0b1f..405861322596 100644
--- a/drivers/irqchip/irq-dw-apb-ictl.c
+++ b/drivers/irqchip/irq-dw-apb-ictl.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#define APB_INT_ENABLE_L 0x00
#define APB_INT_ENABLE_H 0x04
@@ -26,6 +27,30 @@
#define APB_INT_FINALSTATUS_H 0x34
#define APB_INT_BASE_OFFSET0x04
+/*
+ * irq domain of the primary interrupt controller. Currently, only one is
+ * supported.
+ */
+static struct irq_domain *dw_apb_ictl_irq_domain;
+
+static void __exception_irq_entry dw_apb_ictl_handle_irq(struct pt_regs *regs)
+{
+ struct irq_domain *d = dw_apb_ictl_irq_domain;
+ int n;
+
+ for (n = 0; n < d->revmap_size; n += 32) {
+ struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, n);
+ u32 stat = readl_relaxed(gc->reg_base + APB_INT_FINALSTATUS_L);
+
+ while (stat) {
+ u32 hwirq = ffs(stat) - 1;
+
+ handle_domain_irq(d, hwirq, regs);
+ stat &= ~(1 << hwirq);
+ }
+ }
+}
+
static void dw_apb_ictl_handle_irq_cascaded(struct irq_desc *desc)
{
struct irq_domain *d = irq_desc_get_handler_data(desc);
@@ -50,6 +75,30 @@ static void dw_apb_ictl_handle_irq_cascaded(struct irq_desc
*desc)
chained_irq_exit(chip, desc);
}
+static int dw_apb_ictl_irq_domain_alloc(struct irq_domain *domain, unsigned
int virq,
+ unsigned int nr_irqs, void *arg)
+{
+ int i, ret;
+ irq_hw_number_t hwirq;
+ unsigned int type = IRQ_TYPE_NONE;
+ struct irq_fwspec *fwspec = arg;
+
+ ret = irq_domain_translate_onecell(domain, fwspec, , );
+ if (ret)
+ return ret;
+
+ for (i = 0; i < nr_irqs; i++)
+ irq_map_generic_chip(domain, virq + i, hwirq + i);
+
+ return 0;
+}
+
+static const struct irq_domain_ops dw_apb_ictl_irq_domain_ops = {
+ .translate = irq_domain_translate_onecell,
+ .alloc = dw_apb_ictl_irq_domain_alloc,
+ .free = irq_domain_free_irqs_top,
+};
+
#ifdef CONFIG_PM
static void dw_apb_ictl_resume(struct irq_data *d)
{
@@ -78,11 +127,24 @@ static int __init dw_apb_ictl_init(struct device_node *np,
const struct irq_domain_ops *domain_ops = _generic_chip_ops;
irq_flow_handler_t flow_handler = handle_level_irq;
+ if (dw_apb_ictl_irq_domain) {
+ pr_err("%pOF: a hierarchy irq domain is already exist.\n", np);
+ return -EBUSY;
+ }
+
/* Map the parent interrupt for the chained handler */
parent_irq = irq_of_parse_and_map(np, 0);
if (parent_irq <= 0) {
- pr_err("%pOF: unable to parse irq\n", np);
- return -EINVAL;
+ /* It's used as secondary interrupt controller */
+ if (of_find_property(np, "interrupts", NULL)) {
+ pr_err("%pOF: unable to parse irq\n", np);
+ return -EINVAL;
+ }
+
+ /* It's used as the primary interrupt controller */
+ parent_irq = 0;
+ domain_ops = _apb_ictl_irq_domain_ops;
+ flow_handler = handle_fasteoi_irq;
}
ret = of_address_to_resource(np, 0, );
@@ -145,10 +207,17 @@ static int __init dw_apb_ictl_init(struct device_node *np,
gc->chip_types[0].chip.irq_mask = irq_gc_mask_set_bit;
gc->chip_types[0].chip.irq_unmask = irq_gc_mask_clr_bit;
gc->chip_types[0].chip.irq_resume = dw_apb_ictl_resume;
+ if (!parent_irq)
+ gc->chip_types[0].chip.irq_eoi = irq_gc_noop;
}
- irq_set_chained_handler_and_data(parent_irq,
+ if (parent_irq) {
+ irq_set_chained_handler_and_data(parent_irq,
dw_apb_ictl_handle_irq_cascaded, domain);
+ } else {
+ dw_apb_ictl_irq_domain = domain;
+ set_handle_irq(dw_apb_ictl_handle_irq);
+ }
return 0;
--
2.26.0.106.g9fadedd
[PATCH v2 0/3] irqchip: dw-apb-ictl: support hierarchy irq domain
v1 --> v2: According to Marc Zyngier's suggestion, discard adding an independent SD5203-VIC driver, but make the dw-apb-ictl irqchip driver to support hierarchy irq domain. It was originally available only for secondary interrupt controller, now it can also be used as primary interrupt controller. The related dt-bindings is updated appropriately. Add "Suggested-by: Marc Zyngier ". Add "Tested-by: Haoyu Lv ". v1: The interrupt controller of SD5203 SoC is VIC(vector interrupt controller), it's based on Synopsys DesignWare APB interrupt controller (dw_apb_ictl) IP, but it can not directly use dw_apb_ictl driver. The main reason is that VIC is used as primary interrupt controller and dw_apb_ictl driver worked for secondary interrupt controller. So add a new driver: "hisilicon,sd5203-vic". Zhen Lei (3): irqchip: dw-apb-ictl: prepare for support hierarchy irq domain irqchip: dw-apb-ictl: support hierarchy irq domain dt-bindings: dw-apb-ictl: support hierarchy irq domain .../interrupt-controller/snps,dw-apb-ictl.txt | 14 ++- drivers/irqchip/Kconfig | 2 +- drivers/irqchip/irq-dw-apb-ictl.c | 91 +-- 3 files changed, 95 insertions(+), 12 deletions(-) -- 2.26.0.106.g9fadedd
[PATCH v2 1/3] irqchip: dw-apb-ictl: prepare for support hierarchy irq domain
Rename some functions and variables in advance, to make the next patch
looks more clear. The details are as follows:
1. rename dw_apb_ictl_handler() to dw_apb_ictl_handle_irq_cascaded().
In function dw_apb_ictl_init():
1. rename local variable irq to parent_irq.
2. add "const struct irq_domain_ops *domain_ops = _generic_chip_ops",
then replace _generic_chip_ops in other places with domain_ops.
3. add "irq_flow_handler_t flow_handler = handle_level_irq",
then replace handle_level_irq in other places with flow_handler.
No functional change.
Signed-off-by: Zhen Lei
Tested-by: Haoyu Lv
---
drivers/irqchip/irq-dw-apb-ictl.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/irqchip/irq-dw-apb-ictl.c
b/drivers/irqchip/irq-dw-apb-ictl.c
index e4550e9c810b..aa6214da0b1f 100644
--- a/drivers/irqchip/irq-dw-apb-ictl.c
+++ b/drivers/irqchip/irq-dw-apb-ictl.c
@@ -26,7 +26,7 @@
#define APB_INT_FINALSTATUS_H 0x34
#define APB_INT_BASE_OFFSET0x04
-static void dw_apb_ictl_handler(struct irq_desc *desc)
+static void dw_apb_ictl_handle_irq_cascaded(struct irq_desc *desc)
{
struct irq_domain *d = irq_desc_get_handler_data(desc);
struct irq_chip *chip = irq_desc_get_chip(desc);
@@ -73,12 +73,14 @@ static int __init dw_apb_ictl_init(struct device_node *np,
struct irq_domain *domain;
struct irq_chip_generic *gc;
void __iomem *iobase;
- int ret, nrirqs, irq, i;
+ int ret, nrirqs, parent_irq, i;
u32 reg;
+ const struct irq_domain_ops *domain_ops = _generic_chip_ops;
+ irq_flow_handler_t flow_handler = handle_level_irq;
/* Map the parent interrupt for the chained handler */
- irq = irq_of_parse_and_map(np, 0);
- if (irq <= 0) {
+ parent_irq = irq_of_parse_and_map(np, 0);
+ if (parent_irq <= 0) {
pr_err("%pOF: unable to parse irq\n", np);
return -EINVAL;
}
@@ -120,8 +122,7 @@ static int __init dw_apb_ictl_init(struct device_node *np,
else
nrirqs = fls(readl_relaxed(iobase + APB_INT_ENABLE_L));
- domain = irq_domain_add_linear(np, nrirqs,
- _generic_chip_ops, NULL);
+ domain = irq_domain_add_linear(np, nrirqs, domain_ops, NULL);
if (!domain) {
pr_err("%pOF: unable to add irq domain\n", np);
ret = -ENOMEM;
@@ -129,7 +130,7 @@ static int __init dw_apb_ictl_init(struct device_node *np,
}
ret = irq_alloc_domain_generic_chips(domain, 32, 1, np->name,
-handle_level_irq, clr, 0,
+flow_handler, clr, 0,
IRQ_GC_INIT_MASK_CACHE);
if (ret) {
pr_err("%pOF: unable to alloc irq domain gc\n", np);
@@ -146,7 +147,8 @@ static int __init dw_apb_ictl_init(struct device_node *np,
gc->chip_types[0].chip.irq_resume = dw_apb_ictl_resume;
}
- irq_set_chained_handler_and_data(irq, dw_apb_ictl_handler, domain);
+ irq_set_chained_handler_and_data(parent_irq,
+ dw_apb_ictl_handle_irq_cascaded, domain);
return 0;
--
2.26.0.106.g9fadedd
[PATCH v2] KVM: LAPIC: Reduce world switch latency caused by timer_advance_ns
From: Wanpeng Li
All the checks in lapic_timer_int_injected(), __kvm_wait_lapic_expire(), and
these function calls waste cpu cycles when the timer mode is not tscdeadline.
We can observe ~1.3% world switch time overhead by kvm-unit-tests/vmexit.flat
vmcall testing on AMD server. This patch reduces the world switch latency
caused by timer_advance_ns feature when the timer mode is not tscdeadline by
simpling move the check against apic->lapic_timer.expired_tscdeadline much
earlier.
Signed-off-by: Wanpeng Li
---
v1 -> v2:
* move the check against apic->lapic_timer.expired_tscdeadline much earlier
instead of reset timer_advance_ns
arch/x86/kvm/lapic.c | 11 +--
arch/x86/kvm/svm/svm.c | 4 +---
arch/x86/kvm/vmx/vmx.c | 4 +---
3 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 3b32d3b..51ed4f0 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1582,9 +1582,6 @@ static void __kvm_wait_lapic_expire(struct kvm_vcpu *vcpu)
struct kvm_lapic *apic = vcpu->arch.apic;
u64 guest_tsc, tsc_deadline;
- if (apic->lapic_timer.expired_tscdeadline == 0)
- return;
-
tsc_deadline = apic->lapic_timer.expired_tscdeadline;
apic->lapic_timer.expired_tscdeadline = 0;
guest_tsc = kvm_read_l1_tsc(vcpu, rdtsc());
@@ -1599,7 +1596,10 @@ static void __kvm_wait_lapic_expire(struct kvm_vcpu
*vcpu)
void kvm_wait_lapic_expire(struct kvm_vcpu *vcpu)
{
- if (lapic_timer_int_injected(vcpu))
+ if (lapic_in_kernel(vcpu) &&
+ vcpu->arch.apic->lapic_timer.expired_tscdeadline &&
+ vcpu->arch.apic->lapic_timer.timer_advance_ns &&
+ lapic_timer_int_injected(vcpu))
__kvm_wait_lapic_expire(vcpu);
}
EXPORT_SYMBOL_GPL(kvm_wait_lapic_expire);
@@ -1635,8 +1635,7 @@ static void apic_timer_expired(struct kvm_lapic *apic,
bool from_timer_fn)
}
if (kvm_use_posted_timer_interrupt(apic->vcpu)) {
- if (apic->lapic_timer.timer_advance_ns)
- __kvm_wait_lapic_expire(vcpu);
+ kvm_wait_lapic_expire(vcpu);
kvm_apic_inject_pending_timer_irqs(apic);
return;
}
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 0194336..19e622a 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3456,9 +3456,7 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu
*vcpu)
clgi();
kvm_load_guest_xsave_state(vcpu);
- if (lapic_in_kernel(vcpu) &&
- vcpu->arch.apic->lapic_timer.timer_advance_ns)
- kvm_wait_lapic_expire(vcpu);
+ kvm_wait_lapic_expire(vcpu);
/*
* If this vCPU has touched SPEC_CTRL, restore the guest's value if
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index a544351..d6e1656 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6800,9 +6800,7 @@ static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu)
if (enable_preemption_timer)
vmx_update_hv_timer(vcpu);
- if (lapic_in_kernel(vcpu) &&
- vcpu->arch.apic->lapic_timer.timer_advance_ns)
- kvm_wait_lapic_expire(vcpu);
+ kvm_wait_lapic_expire(vcpu);
/*
* If this vCPU has touched SPEC_CTRL, restore the guest's value if
--
2.7.4
[PATCH 3/3] Documentation: fpga: dfl: Add description for VFIO Mdev support
This patch adds description for VFIO Mdev support for dfl devices on dfl bus. Signed-off-by: Xu Yilun Signed-off-by: Matthew Gerlach --- Documentation/fpga/dfl.rst | 20 1 file changed, 20 insertions(+) diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst index 0404fe6..f077754 100644 --- a/Documentation/fpga/dfl.rst +++ b/Documentation/fpga/dfl.rst @@ -502,6 +502,26 @@ FME Partial Reconfiguration Sub Feature driver (see drivers/fpga/dfl-fme-pr.c) could be a reference. +VFIO Mdev support for DFL devices += +As we introduced a dfl bus for private features, they could be added to dfl bus +as independent dfl devices. There is a requirement to handle these devices +either by kernel drivers or by direct access from userspace. Usually we bind +the kernel drivers to devices which provide board management functions, and +gives user direct access to devices which cooperate closely with user +controlled Accelerated Function Unit (AFU). We realize this with a VFIO Mdev +implementation. When we bind the vfio-mdev-dfl driver to a dfl device, it +realizes a group of callbacks and registers to the Mdev framework as a +parent (physical) device. It could then create one (available_instances == 1) +mdev device. +Since dfl devices are sub devices of FPGA DFL physical devices (e.g. PCIE +device), which provide no DMA isolation for each sub device, this may leads to +DMA isolation problem if a private feature is designed to be capable of DMA. +The AFU user could potentially access the whole device addressing space and +impact the private feature. So now the general HW design rule is, no DMA +capability for private features. It eliminates the DMA isolation problem. + + Open discussion === FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration -- 2.7.4
[PATCH V3 3/3] pinctrl: imx: Support building i.MX pinctrl core driver as module
Change PINCTRL_IMX to tristate to support loadable module build.
And i.MX common pinctrl driver should depend on CONFIG_OF to make sure
no build error when i.MX common pinctrl driver is enabled for different
architectures without CONFIG_OF.
Also add module author, description and license.
Signed-off-by: Anson Huang
Reviewed-by: Dong Aisheng
---
no change.
---
drivers/pinctrl/freescale/Kconfig | 3 ++-
drivers/pinctrl/freescale/pinctrl-imx.c | 5 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/freescale/Kconfig
b/drivers/pinctrl/freescale/Kconfig
index 452c499..0058d3a 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config PINCTRL_IMX
- bool
+ tristate "IMX pinctrl core driver"
+ depends on OF
select GENERIC_PINCTRL_GROUPS
select GENERIC_PINMUX_FUNCTIONS
select GENERIC_PINCONF
diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
b/drivers/pinctrl/freescale/pinctrl-imx.c
index b80c450..daf28bc 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -898,3 +899,7 @@ const struct dev_pm_ops imx_pinctrl_pm_ops = {
imx_pinctrl_resume)
};
EXPORT_SYMBOL_GPL(imx_pinctrl_pm_ops);
+
+MODULE_AUTHOR("Dong Aisheng ");
+MODULE_DESCRIPTION("NXP i.MX common pinctrl driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
[PATCH V3 1/3] pinctrl: imx: Use function callbacks for SCU related functions
Use function callbacks for SCU related functions in pinctrl-imx.c
in order to support the scenario of PINCTRL_IMX is built in while
PINCTRL_IMX_SCU is built as module, all drivers using SCU pinctrl
driver need to initialize the SCU related function callback, and
no need to check CONFIG_PINCTRL_IMX_SCU anymore, hence stub functions
also can be removed.
Signed-off-by: Anson Huang
---
Changes since V2:
- move the removal of #ifdef CONFIG_PINCTRL_IMX_SCU and #else block from
patch #2 to this patch.
---
drivers/pinctrl/freescale/pinctrl-imx.c | 8 ++--
drivers/pinctrl/freescale/pinctrl-imx.h | 57 +++--
drivers/pinctrl/freescale/pinctrl-imx8dxl.c | 3 ++
drivers/pinctrl/freescale/pinctrl-imx8qm.c | 3 ++
drivers/pinctrl/freescale/pinctrl-imx8qxp.c | 3 ++
5 files changed, 35 insertions(+), 39 deletions(-)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
b/drivers/pinctrl/freescale/pinctrl-imx.c
index 507e4af..b80c450 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -373,7 +373,7 @@ static int imx_pinconf_get(struct pinctrl_dev *pctldev,
const struct imx_pinctrl_soc_info *info = ipctl->info;
if (info->flags & IMX_USE_SCU)
- return imx_pinconf_get_scu(pctldev, pin_id, config);
+ return info->imx_pinconf_get(pctldev, pin_id, config);
else
return imx_pinconf_get_mmio(pctldev, pin_id, config);
}
@@ -423,7 +423,7 @@ static int imx_pinconf_set(struct pinctrl_dev *pctldev,
const struct imx_pinctrl_soc_info *info = ipctl->info;
if (info->flags & IMX_USE_SCU)
- return imx_pinconf_set_scu(pctldev, pin_id,
+ return info->imx_pinconf_set(pctldev, pin_id,
configs, num_configs);
else
return imx_pinconf_set_mmio(pctldev, pin_id,
@@ -440,7 +440,7 @@ static void imx_pinconf_dbg_show(struct pinctrl_dev
*pctldev,
int ret;
if (info->flags & IMX_USE_SCU) {
- ret = imx_pinconf_get_scu(pctldev, pin_id, );
+ ret = info->imx_pinconf_get(pctldev, pin_id, );
if (ret) {
dev_err(ipctl->dev, "failed to get %s pinconf\n",
pin_get_name(pctldev, pin_id));
@@ -629,7 +629,7 @@ static int imx_pinctrl_parse_groups(struct device_node *np,
for (i = 0; i < grp->num_pins; i++) {
pin = &((struct imx_pin *)(grp->data))[i];
if (info->flags & IMX_USE_SCU)
- imx_pinctrl_parse_pin_scu(ipctl, >pins[i],
+ info->imx_pinctrl_parse_pin(ipctl, >pins[i],
pin, );
else
imx_pinctrl_parse_pin_mmio(ipctl, >pins[i],
diff --git a/drivers/pinctrl/freescale/pinctrl-imx.h
b/drivers/pinctrl/freescale/pinctrl-imx.h
index 333d32b..fd8c4b6 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.h
+++ b/drivers/pinctrl/freescale/pinctrl-imx.h
@@ -75,6 +75,21 @@ struct imx_cfg_params_decode {
bool invert;
};
+/**
+ * @dev: a pointer back to containing device
+ * @base: the offset to the controller in virtual memory
+ */
+struct imx_pinctrl {
+ struct device *dev;
+ struct pinctrl_dev *pctl;
+ void __iomem *base;
+ void __iomem *input_sel_base;
+ const struct imx_pinctrl_soc_info *info;
+ struct imx_pin_reg *pin_regs;
+ unsigned int group_index;
+ struct mutex mutex;
+};
+
struct imx_pinctrl_soc_info {
const struct pinctrl_pin_desc *pins;
unsigned int npins;
@@ -98,21 +113,13 @@ struct imx_pinctrl_soc_info {
struct pinctrl_gpio_range *range,
unsigned offset,
bool input);
-};
-
-/**
- * @dev: a pointer back to containing device
- * @base: the offset to the controller in virtual memory
- */
-struct imx_pinctrl {
- struct device *dev;
- struct pinctrl_dev *pctl;
- void __iomem *base;
- void __iomem *input_sel_base;
- const struct imx_pinctrl_soc_info *info;
- struct imx_pin_reg *pin_regs;
- unsigned int group_index;
- struct mutex mutex;
+ int (*imx_pinconf_get)(struct pinctrl_dev *pctldev, unsigned int pin_id,
+ unsigned long *config);
+ int (*imx_pinconf_set)(struct pinctrl_dev *pctldev, unsigned int pin_id,
+ unsigned long *configs, unsigned int
num_configs);
+ void (*imx_pinctrl_parse_pin)(struct imx_pinctrl *ipctl,
+ unsigned int *pin_id, struct imx_pin *pin,
+ const __be32 **list_p);
};
#define IMX_CFG_PARAMS_DECODE(p, m, o) \
@@ -137,7 +144,6 @@ struct imx_pinctrl {
int imx_pinctrl_probe(struct platform_device *pdev,
[PATCH 2/3] fpga: dfl: VFIO mdev support for DFL devices
This patch is to provide VFIO support to DFL devices. When bound this
driver to a dfl device, it registers a set of callbacks to the mediated
device framework to enable mediated device creation. When a mediated
device is created by user via mdev interfaces, it will be exposed to
user as a VFIO platform device.
Signed-off-by: Xu Yilun
---
drivers/fpga/Kconfig | 9 +
drivers/fpga/Makefile| 1 +
drivers/fpga/vfio-mdev-dfl.c | 391 +++
3 files changed, 401 insertions(+)
create mode 100644 drivers/fpga/vfio-mdev-dfl.c
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 38c7130..88f64fb 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -202,6 +202,15 @@ config FPGA_DFL_NIOS_INTEL_PAC_N3000
the card. It also instantiates the SPI master (spi-altera) for
the card's BMC (Board Management Controller) control.
+config FPGA_VFIO_MDEV_DFL
+tristate "VFIO Mdev support for DFL devices"
+depends on FPGA_DFL && VFIO_MDEV
+help
+ Support for DFL devices with VFIO Mdev. This is required to make use
+ of DFL devices present on the system using the VFIO Mdev framework.
+
+ If you don't know what to do here, say N.
+
config FPGA_DFL_PCI
tristate "FPGA DFL PCIe Device Driver"
depends on PCI && FPGA_DFL
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 18dc9885..c69bfc9 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -45,6 +45,7 @@ dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o
dfl-afu-dma-region.o
dfl-afu-objs += dfl-afu-error.o
obj-$(CONFIG_FPGA_DFL_NIOS_INTEL_PAC_N3000)+= dfl-n3000-nios.o
+obj-$(CONFIG_FPGA_VFIO_MDEV_DFL) += vfio-mdev-dfl.o
# Drivers for FPGAs which implement DFL
obj-$(CONFIG_FPGA_DFL_PCI) += dfl-pci.o
diff --git a/drivers/fpga/vfio-mdev-dfl.c b/drivers/fpga/vfio-mdev-dfl.c
new file mode 100644
index 000..34fb19f
--- /dev/null
+++ b/drivers/fpga/vfio-mdev-dfl.c
@@ -0,0 +1,391 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * VFIO Mediated device driver for DFL devices
+ *
+ * Copyright (C) 2019-2020 Intel Corporation, Inc.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct vfio_mdev_dfl_dev {
+ struct device *dev;
+ void __iomem *ioaddr;
+ resource_size_t phys;
+ resource_size_t memsize;
+ int num_irqs;
+ u32 region_flags;
+ atomic_t avail;
+};
+
+static ssize_t
+name_show(struct kobject *kobj, struct device *dev, char *buf)
+{
+ return sprintf(buf, "%s-type1\n", dev_name(dev));
+}
+static MDEV_TYPE_ATTR_RO(name);
+
+static ssize_t
+available_instances_show(struct kobject *kobj, struct device *dev, char *buf)
+{
+ struct vfio_mdev_dfl_dev *vmdd = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%d\n", atomic_read(>avail));
+}
+static MDEV_TYPE_ATTR_RO(available_instances);
+
+static ssize_t device_api_show(struct kobject *kobj, struct device *dev,
+ char *buf)
+{
+ return sprintf(buf, "%s\n", VFIO_DEVICE_API_PLATFORM_STRING);
+}
+static MDEV_TYPE_ATTR_RO(device_api);
+
+static struct attribute *mdev_types_attrs[] = {
+ _type_attr_name.attr,
+ _type_attr_device_api.attr,
+ _type_attr_available_instances.attr,
+ NULL,
+};
+
+static struct attribute_group dfl_mdev_type_group1 = {
+ .name = "1",
+ .attrs = mdev_types_attrs,
+};
+
+static struct attribute_group *dfl_mdev_type_groups[] = {
+ _mdev_type_group1,
+ NULL,
+};
+
+static int dfl_mdev_create(struct kobject *kobj, struct mdev_device *mdev)
+{
+ struct vfio_mdev_dfl_dev *vmdd =
+ dev_get_drvdata(mdev_parent_dev(mdev));
+
+ if (atomic_dec_if_positive(>avail) < 0)
+ return -EPERM;
+
+ return 0;
+}
+
+static int dfl_mdev_remove(struct mdev_device *mdev)
+{
+ struct vfio_mdev_dfl_dev *vmdd =
+ dev_get_drvdata(mdev_parent_dev(mdev));
+
+ atomic_inc(>avail);
+
+ return 0;
+}
+
+static ssize_t dfl_mdev_read(struct mdev_device *mdev, char __user *buf,
+size_t count, loff_t *ppos)
+{
+ struct vfio_mdev_dfl_dev *vmdd =
+ dev_get_drvdata(mdev_parent_dev(mdev));
+ unsigned int done = 0;
+ loff_t off = *ppos;
+
+ if (off + count > vmdd->memsize)
+ return -EFAULT;
+
+ while (count) {
+ size_t filled;
+
+ if (count >= 8 && !(off % 8)) {
+ u64 val;
+
+ val = ioread64(vmdd->ioaddr + off);
+ if (copy_to_user(buf, , 8))
+ goto err;
+
+ filled = 8;
+ } else if (count >= 4 && !(off % 4)) {
+ u32 val;
+
+ val = ioread32(vmdd->ioaddr +
[PATCH V3 2/3] pinctrl: imx: Support building SCU pinctrl core driver as module
Change PINCTR_IMX_SCU to tristate, add module author, description
and license to support building SCU pinctrl core driver as module.
Signed-off-by: Anson Huang
---
Changes since V2:
- move the removal of #ifdef CONFIG_PINCTRL_IMX_SCU and #else block to
patch #1.
---
drivers/pinctrl/freescale/Kconfig | 2 +-
drivers/pinctrl/freescale/pinctrl-scu.c | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/freescale/Kconfig
b/drivers/pinctrl/freescale/Kconfig
index 08fcf5c..452c499 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -7,7 +7,7 @@ config PINCTRL_IMX
select REGMAP
config PINCTRL_IMX_SCU
- bool
+ tristate "IMX SCU pinctrl core driver"
depends on IMX_SCU
select PINCTRL_IMX
diff --git a/drivers/pinctrl/freescale/pinctrl-scu.c
b/drivers/pinctrl/freescale/pinctrl-scu.c
index 9df45d3..59b5f8a 100644
--- a/drivers/pinctrl/freescale/pinctrl-scu.c
+++ b/drivers/pinctrl/freescale/pinctrl-scu.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include
#include
@@ -123,3 +124,7 @@ void imx_pinctrl_parse_pin_scu(struct imx_pinctrl *ipctl,
pin_scu->mux_mode, pin_scu->config);
}
EXPORT_SYMBOL_GPL(imx_pinctrl_parse_pin_scu);
+
+MODULE_AUTHOR("Dong Aisheng ");
+MODULE_DESCRIPTION("NXP i.MX SCU common pinctrl driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
Re: 答复: [PATCH v2 6/6] drm/panel: Add Ilitek ILI9341 DBI panel driver
On 07/09/2020 14:57, Paul Cercueil wrote: > > > Le dim. 30 août 2020 à 22:28, Sam Ravnborg a écrit : >> Hi Laurent. >> >>> > >>> > Please read the cover letter, it explains why it's done this way. The >>> > whole point of this patchset is to merge DSI and DBI frameworks in a >>> > way that can be maintained. >>> >>> I think this proves the point that the proposed naming is confusing. At >>> least a rename would be required. >> >> Do you have any inputs on the amount of rename we are looking into. >> Is this a simple s/struct mipi_dsi_device/struct mipi_dxi_device/ >> or something more? >> >> We should script the rename as it will tocuh a lot of files, >> and without a script we would chase this. But once it is scripted >> it would be trivial to perform. >> >> I did not look at this enough, but I had an idea that we >> would have do to a s/dsi/dxi/ in a lot of places. >> >> (dxi is my best proposal at the moment for something covering both dsi >> and dbi). > > dcs? > > Since DBI and DSI panels generally all use DCS commands. mipi_disp / mipi_display ? since it's all about mipi display interfaces with different transport protocols. Neil > > -Paul > > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] arm64/mm: Use CONT_SHIFT to define CONT_PTE_SHIFT
The macro CONT_PTE_SHIFT actually depends on CONT_SHIFT, which has been defined in page-def.h, based on CONFIG_ARM64_CONT_SHIFT. Lets reflect the dependency. Signed-off-by: Gavin Shan --- arch/arm64/include/asm/pgtable-hwdef.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h index 8a399e666837..0bd9469f4323 100644 --- a/arch/arm64/include/asm/pgtable-hwdef.h +++ b/arch/arm64/include/asm/pgtable-hwdef.h @@ -81,14 +81,12 @@ /* * Contiguous page definitions. */ +#define CONT_PTE_SHIFT (CONT_SHIFT + PAGE_SHIFT) #ifdef CONFIG_ARM64_64K_PAGES -#define CONT_PTE_SHIFT (5 + PAGE_SHIFT) #define CONT_PMD_SHIFT (5 + PMD_SHIFT) #elif defined(CONFIG_ARM64_16K_PAGES) -#define CONT_PTE_SHIFT (7 + PAGE_SHIFT) #define CONT_PMD_SHIFT (5 + PMD_SHIFT) #else -#define CONT_PTE_SHIFT (4 + PAGE_SHIFT) #define CONT_PMD_SHIFT (4 + PMD_SHIFT) #endif -- 2.23.0
[PATCH 1/2] arm64/mm: Remove CONT_RANGE_OFFSET
The macro was introduced by commit ("arm64: PTE/PMD
contiguous bit definition") at the beginning. It's only used by
commit <348a65cdcbbf> ("arm64: Mark kernel page ranges contiguous"),
which was reverted later by commit <667c27597ca8>. This makes the
macro unused.
This removes the unused macro (CONT_RANGE_OFFSET).
Signed-off-by: Gavin Shan
---
arch/arm64/include/asm/pgtable-hwdef.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h
b/arch/arm64/include/asm/pgtable-hwdef.h
index d400a4d9aee2..8a399e666837 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -98,8 +98,6 @@
#define CONT_PMDS (1 << (CONT_PMD_SHIFT - PMD_SHIFT))
#define CONT_PMD_SIZE (CONT_PMDS * PMD_SIZE)
#define CONT_PMD_MASK (~(CONT_PMD_SIZE - 1))
-/* the numerical offset of the PTE within a range of CONT_PTES */
-#define CONT_RANGE_OFFSET(addr) (((addr)>>PAGE_SHIFT)&(CONT_PTES-1))
/*
* Hardware page table definitions.
--
2.23.0
[PATCH 1/3] fpga: dfl: add driver_override support
Add support for overriding the default matching of a dfl device to a dfl
driver. It follows the same way that can be used for PCI and platform
devices. This patch adds the 'driver_override' sysfs file. It can be
used by VFIO to bind dfl devices for user accessing.
Signed-off-by: Xu Yilun
---
Documentation/ABI/testing/sysfs-bus-dfl | 20
drivers/fpga/dfl.c | 54 -
include/linux/fpga/dfl-bus.h| 2 ++
3 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-dfl
b/Documentation/ABI/testing/sysfs-bus-dfl
index 23543be..cf1357a 100644
--- a/Documentation/ABI/testing/sysfs-bus-dfl
+++ b/Documentation/ABI/testing/sysfs-bus-dfl
@@ -13,3 +13,23 @@ Contact: Xu Yilun
Description: Read-only. It returns feature identifier local to its DFL FIU
type.
Format: 0x%x
+
+What: /sys/bus/dfl/devices/.../driver_override
+Date: Sep 2020
+KernelVersion: 5.10
+Contact: Xu Yilun
+Description: This file allows the driver for a device to be specified. When
+ specified, only a driver with a name matching the value written
+ to driver_override will have an opportunity to bind to the
+ device. The override is specified by writing a string to the
+ driver_override file (echo vfio-mdev-dfl > driver_override) and
+ may be cleared with an empty string (echo > driver_override).
+ This returns the device to standard matching rules binding.
+ Writing to driver_override does not automatically unbind the
+ device from its current driver or make any attempt to
+ automatically load the specified driver. If no driver with a
+ matching name is currently loaded in the kernel, the device
+ will not bind to any driver. This also allows devices to
+ opt-out of driver binding using a driver_override name such as
+ "none". Only a single driver may be specified in the override,
+ there is no support for parsing delimiters.
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index 02a6780..98f88ee 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -262,6 +262,10 @@ static int dfl_bus_match(struct device *dev, struct
device_driver *drv)
struct dfl_driver *ddrv = to_dfl_drv(drv);
const struct dfl_device_id *id_entry;
+ /* When driver_override is set, only bind to the matching driver */
+ if (ddev->driver_override)
+ return !strcmp(ddev->driver_override, drv->name);
+
id_entry = ddrv->id_table;
if (id_entry) {
while (id_entry->feature_id) {
@@ -304,6 +308,53 @@ static int dfl_bus_uevent(struct device *dev, struct
kobj_uevent_env *env)
ddev->type, ddev->feature_id);
}
+static ssize_t driver_override_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dfl_device *ddev = to_dfl_dev(dev);
+ ssize_t len;
+
+ device_lock(dev);
+ len = sprintf(buf, "%s\n", ddev->driver_override);
+ device_unlock(dev);
+ return len;
+}
+
+static ssize_t driver_override_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct dfl_device *ddev = to_dfl_dev(dev);
+ char *driver_override, *old, *cp;
+
+ /* We need to keep extra room for a newline */
+ if (count >= (PAGE_SIZE - 1))
+ return -EINVAL;
+
+ driver_override = kstrndup(buf, count, GFP_KERNEL);
+ if (!driver_override)
+ return -ENOMEM;
+
+ cp = strchr(driver_override, '\n');
+ if (cp)
+ *cp = '\0';
+
+ device_lock(dev);
+ old = ddev->driver_override;
+ if (strlen(driver_override)) {
+ ddev->driver_override = driver_override;
+ } else {
+ kfree(driver_override);
+ ddev->driver_override = NULL;
+ }
+ device_unlock(dev);
+
+ kfree(old);
+
+ return count;
+}
+static DEVICE_ATTR_RW(driver_override);
+
static ssize_t
type_show(struct device *dev, struct device_attribute *attr, char *buf)
{
@@ -325,6 +376,7 @@ static DEVICE_ATTR_RO(feature_id);
static struct attribute *dfl_dev_attrs[] = {
_attr_type.attr,
_attr_feature_id.attr,
+ _attr_driver_override.attr,
NULL,
};
ATTRIBUTE_GROUPS(dfl_dev);
@@ -470,7 +522,7 @@ static int dfl_devs_add(struct dfl_feature_platform_data
*pdata)
int __dfl_driver_register(struct dfl_driver *dfl_drv, struct module *owner)
{
- if (!dfl_drv || !dfl_drv->probe || !dfl_drv->id_table)
+ if (!dfl_drv || !dfl_drv->probe)
return -EINVAL;
[PATCH 0/3] add VFIO mdev support for DFL devices
These patches depend on the patchset: "Modularization of DFL private feature drivers" & "add dfl bus support to MODULE_DEVICE_TABLE()" https://lore.kernel.org/linux-fpga/1599488581-16386-1-git-send-email-yilun...@intel.com/ This patchset provides an VFIO Mdev driver for dfl devices. It makes possible for dfl devices be direct accessed from userspace. Xu Yilun (3): fpga: dfl: add driver_override support fpga: dfl: VFIO mdev support for DFL devices Documentation: fpga: dfl: Add description for VFIO Mdev support Documentation/ABI/testing/sysfs-bus-dfl | 20 ++ Documentation/fpga/dfl.rst | 20 ++ drivers/fpga/Kconfig| 9 + drivers/fpga/Makefile | 1 + drivers/fpga/dfl.c | 54 - drivers/fpga/vfio-mdev-dfl.c| 391 include/linux/fpga/dfl-bus.h| 2 + 7 files changed, 496 insertions(+), 1 deletion(-) create mode 100644 drivers/fpga/vfio-mdev-dfl.c -- 2.7.4
[PATCH 1/2] usb: dwc3: Add splitdisable quirk for Hisilicon Kirin Soc
From: Yu Chen
SPLIT_BOUNDARY_DISABLE should be set for DesignWare USB3 DRD Core
of Hisilicon Kirin Soc when dwc3 core act as host.
[mchehab: dropped a dev_dbg() as only traces are now allowwed on this driver]
Signed-off-by: Yu Chen
Signed-off-by: Mauro Carvalho Chehab
---
drivers/usb/dwc3/core.c | 25 +
drivers/usb/dwc3/core.h | 7 +++
2 files changed, 32 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 25c686a752b0..e476e83308bc 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -119,6 +119,7 @@ static void __dwc3_set_mode(struct work_struct *work)
struct dwc3 *dwc = work_to_dwc(work);
unsigned long flags;
int ret;
+ u32 reg;
if (dwc->dr_mode != USB_DR_MODE_OTG)
return;
@@ -172,6 +173,11 @@ static void __dwc3_set_mode(struct work_struct *work)
otg_set_vbus(dwc->usb2_phy->otg, true);
phy_set_mode(dwc->usb2_generic_phy, PHY_MODE_USB_HOST);
phy_set_mode(dwc->usb3_generic_phy, PHY_MODE_USB_HOST);
+ if (dwc->dis_split_quirk) {
+ reg = dwc3_readl(dwc->regs, DWC3_GUCTL3);
+ reg |= DWC3_GUCTL3_SPLITDISABLE;
+ dwc3_writel(dwc->regs, DWC3_GUCTL3, reg);
+ }
}
break;
case DWC3_GCTL_PRTCAP_DEVICE:
@@ -1357,6 +1363,9 @@ static void dwc3_get_properties(struct dwc3 *dwc)
dwc->dis_metastability_quirk = device_property_read_bool(dev,
"snps,dis_metastability_quirk");
+ dwc->dis_split_quirk = device_property_read_bool(dev,
+ "snps,dis-split-quirk");
+
dwc->lpm_nyet_threshold = lpm_nyet_threshold;
dwc->tx_de_emphasis = tx_de_emphasis;
@@ -1866,10 +1875,26 @@ static int dwc3_resume(struct device *dev)
return 0;
}
+
+static void dwc3_complete(struct device *dev)
+{
+ struct dwc3 *dwc = dev_get_drvdata(dev);
+ u32 reg;
+
+ if (dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST &&
+ dwc->dis_split_quirk) {
+ reg = dwc3_readl(dwc->regs, DWC3_GUCTL3);
+ reg |= DWC3_GUCTL3_SPLITDISABLE;
+ dwc3_writel(dwc->regs, DWC3_GUCTL3, reg);
+ }
+}
+#else
+#define dwc3_complete NULL
#endif /* CONFIG_PM_SLEEP */
static const struct dev_pm_ops dwc3_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
+ .complete = dwc3_complete,
SET_RUNTIME_PM_OPS(dwc3_runtime_suspend, dwc3_runtime_resume,
dwc3_runtime_idle)
};
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 013f42a2b5dc..af5533b09713 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -138,6 +138,7 @@
#define DWC3_GEVNTCOUNT(n) (0xc40c + ((n) * 0x10))
#define DWC3_GHWPARAMS80xc600
+#define DWC3_GUCTL30xc60c
#define DWC3_GFLADJ0xc630
/* Device Registers */
@@ -380,6 +381,9 @@
/* Global User Control Register 2 */
#define DWC3_GUCTL2_RST_ACTBITLATERBIT(14)
+/* Global User Control Register 3 */
+#define DWC3_GUCTL3_SPLITDISABLE BIT(14)
+
/* Device Configuration Register */
#define DWC3_DCFG_DEVADDR(addr)((addr) << 3)
#define DWC3_DCFG_DEVADDR_MASK DWC3_DCFG_DEVADDR(0x7f)
@@ -1052,6 +1056,7 @@ struct dwc3_scratchpad_array {
* 2 - No de-emphasis
* 3 - Reserved
* @dis_metastability_quirk: set to disable metastability quirk.
+ * @dis_split_quirk: set to disable split boundary.
* @imod_interval: set the interrupt moderation interval in 250ns
* increments or 0 to disable.
*/
@@ -1245,6 +1250,8 @@ struct dwc3 {
unsigneddis_metastability_quirk:1;
+ unsigneddis_split_quirk:1;
+
u16 imod_interval;
};
--
2.26.2
[PATCH 0/2] Add a quirk for dwc3 driver, requred for Hikey 970 USB to work
This small patch series add a new quirk for the dwc3 driver. The first patch was submitted previously to the USB mailing list: https://patchwork.kernel.org/patch/10909965/ This quirk is also present at the official Linaro's tree for Hikey 970. Without that, the URBs produced by the USB HID driver returns -EPROTO errors, causing an endless reset loop, on every 0.5 seconds. Please notice that I don't have any documentation about Synopsys dwc3 driver. So, I tried my best to document this quirk at patch 2, but I can't add anything more specifics, as I don't have any datasheets from such IP. Mauro Carvalho Chehab (1): dt-bindings: document a new quirk for dwc3 Yu Chen (1): usb: dwc3: Add splitdisable quirk for Hisilicon Kirin Soc .../devicetree/bindings/usb/dwc3.txt | 3 +++ drivers/usb/dwc3/core.c | 25 +++ drivers/usb/dwc3/core.h | 7 ++ 3 files changed, 35 insertions(+) -- 2.26.2
[PATCH 2/2] dt-bindings: document a new quirk for dwc3
At Hikey 970, setting the SPLIT disable at the General User Register 3 is required. Without that, the URBs generated by the usbhid driver return -EPROTO errors. That causes the code at hid-core.c to call hid_io_error(), which schedules a reset_work, causing a call to hid_reset(). In turn, the code there will call: usb_queue_reset_device(usbhid->intf); The net result is that the input devices won't work, and will be reset on every 0.5 seconds: [ 33.122384] hub 1-1:1.0: state 7 ports 4 chg evt 0002 [ 33.378220] usb 1-1.1: reset low-speed USB device number 3 using xhci-hcd [ 33.698394] hub 1-1:1.0: state 7 ports 4 chg evt [ 34.882365] hub 1-1:1.0: state 7 ports 4 chg evt 0002 [ 35.138217] usb 1-1.1: reset low-speed USB device number 3 using xhci-hcd [ 35.458617] hub 1-1:1.0: state 7 ports 4 chg evt [ 36.642392] hub 1-1:1.0: state 7 ports 4 chg evt 0002 [ 36.898207] usb 1-1.1: reset low-speed USB device number 3 using xhci-hcd [ 37.218598] hub 1-1:1.0: state 7 ports 4 chg evt [ 38.402368] hub 1-1:1.0: state 7 ports 4 chg evt 0002 [ 38.658174] usb 1-1.1: reset low-speed USB device number 3 using xhci-hcd [ 38.978594] hub 1-1:1.0: state 7 ports 4 chg evt [ 40.162361] hub 1-1:1.0: state 7 ports 4 chg evt 0002 [ 40.418148] usb 1-1.1: reset low-speed USB device number 3 using xhci-hcd ... [ 397.698132] usb 1-1.1: reset low-speed USB device number 3 using xhci-hcd Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/usb/dwc3.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index d03edf9d3935..1aae2b6160c1 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -78,6 +78,9 @@ Optional properties: park mode are disabled. - snps,dis_metastability_quirk: when set, disable metastability workaround. CAUTION: use only if you are absolutely sure of it. + - snps,dis-split-quirk: when set, change the way URBs are handled by the +driver. Needed to avoid -EPROTO errors with usbhid +on some devices (Hikey 970). - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal utmi_l1_suspend_n, false when asserts utmi_sleep_n - snps,hird-threshold: HIRD threshold -- 2.26.2
