Re: [PATCH -tip 22/32] sched: Split the cookie and setup per-task cookie on fork
On Tue, Dec 01, 2020 at 10:36:18PM -0800, Josh Don wrote: > On Tue, Dec 1, 2020 at 11:35 AM Peter Zijlstra wrote: > > > > So I don't think that later patch is right... That is, it works, but > > afaict it's massive overkill. > > > > COOKIE_CMP_RETURN(task_cookie); > > COOKIE_CMP_RETURN(group_cookie); > > COOKIE_CMP_RETURN(color); > > > > So if task_cookie matches, we consider group_cookie, if that matches we > > consider color. > > > > Now, afaict that's semantically exactly the same as just using the > > narrowest cookie. That is, use the task cookie if there is, and then, > > walking the cgroup hierarchy (up) pick the first cgroup cookie. > > > > (I don't understand the color thing, but lets have that discussion in > > that subthread) > > > > Which means you only need a single active cookie field. > > > > IOW, you're just making things complicated and expensive. > > > > For the per-task interface, I believe we still want to prevent two > tasks that share a task cookie from sharing an overall cookie if they > are in two separately tagged groups (Joel please correct me if I'm > mistaken there). That's why in Joel's older patch, the overall cookie > was a combination of the task and group cookies. My concern about > that was the potential cookie collision. Then disallow sharing a task cookie when the tasks are in different cgroups or disallow cgroup movement when they share a cookie.
[PATCH v3 0/1] Fix object remain in offline per-cpu quarantine
This patch fixes object remain in the offline per-cpu quarantine as describe below. Free objects will get into per-cpu quarantine if enable generic KASAN. If a cpu is offline and users use kmem_cache_destroy, kernel will detect objects still remain in the offline per-cpu quarantine and report error. Register a cpu hotplug function to remove all objects in the offline per-cpu quarantine when cpu is going offline. Set a per-cpu variable to indicate this cpu is offline. Changes since v3: - Add a barrier to ensure the ordering - Rename the init function Changes since v2: - Thanks for Dmitry suggestion - Remove unnecessary code - Put offline variable into cpu_quarantine - Use single qlist_free_all call instead of iteration over all slabs - Add bug reporter in commit message Kuan-Ying Lee (1): kasan: fix object remain in offline per-cpu quarantine mm/kasan/quarantine.c | 40 1 file changed, 40 insertions(+) -- 2.18.0
Re: [GIT pull] locking/urgent for v5.10-rc6
> > But but but... > > > > do_idle() # IRQs on > > local_irq_disable();# IRQs off > > defaul_idle_call() # IRQs off > lockdep_hardirqs_on(); # IRQs off, but lockdep things they're on > > arch_cpu_idle() # IRQs off > > enabled_wait() # IRQs off > > raw_local_save() # still off > > psw_idle()# very much off > > ext_int_handler # get an interrupt ?!?! > rcu_irq_enter() # lockdep thinks IRQs are on <- FAIL > > I can't much read s390 assembler, but ext_int_handler() has a > TRACE_IRQS_OFF, which would be sufficient to re-align the lockdep state > with the actual state, but there's some condition before it, what's that > test and is that right? After digging a bit into our asm code: no, it is not right, and only for psw_idle() it is wrong. What happens with the current code: - default_idle_call() calls lockdep_hardirqs_on() before calling into arch_cpu_idle() - our arch_cpu_idle() calls psw_idle() which enables irqs. the irq handler will call/use the SWITCH_ASYNC macro which clears the interrupt enabled bits in the old program status word (_only_ for psw_idle) - this again causes the interrupt handler to _not_ call TRACE_IRQS_OFF and therefore lockdep thinks interrupts are enabled within the interrupt handler So I guess my patch which I sent yesterday evening should fix all that mess - plus an explicit trace_hardirqs_off() call in our udelay implementation is required now. I'll send a proper patch later.
[PATCH] Documentation: fix typos found in process, dev-tools, and doc-guide subdirectories
Fix four typos in kcov.rst, sphinx.rst, clang-format.rst, and embargoed-hardware-issues.rst Signed-off-by: Andrew Klychkov --- Documentation/dev-tools/kcov.rst| 2 +- Documentation/doc-guide/sphinx.rst | 2 +- Documentation/process/clang-format.rst | 2 +- Documentation/process/embargoed-hardware-issues.rst | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/dev-tools/kcov.rst b/Documentation/dev-tools/kcov.rst index 8548b0b..d2c4c27e 100644 --- a/Documentation/dev-tools/kcov.rst +++ b/Documentation/dev-tools/kcov.rst @@ -243,7 +243,7 @@ handles as they don't belong to a particular subsystem. The bytes 4-7 are currently reserved and must be zero. In the future the number of bytes used for the subsystem or handle ids might be increased. -When a particular userspace proccess collects coverage via a common +When a particular userspace process collects coverage via a common handle, kcov will collect coverage for each code section that is annotated to use the common handle obtained as kcov_handle from the current task_struct. However non common handles allow to collect coverage diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst index 896478b..2fb2ff2 100644 --- a/Documentation/doc-guide/sphinx.rst +++ b/Documentation/doc-guide/sphinx.rst @@ -375,7 +375,7 @@ image format use SVG (:ref:`svg_image_example`):: SVG image example -The kernel figure (and image) directive support **DOT** formated files, see +The kernel figure (and image) directive support **DOT** formatted files, see * DOT: http://graphviz.org/pdf/dotguide.pdf * Graphviz: http://www.graphviz.org/content/dot-language diff --git a/Documentation/process/clang-format.rst b/Documentation/process/clang-format.rst index 82676e5..1d089a8 100644 --- a/Documentation/process/clang-format.rst +++ b/Documentation/process/clang-format.rst @@ -97,7 +97,7 @@ it can be very useful. There are integrations for many popular text editors. For some of them, like vim, emacs, BBEdit and Visual Studio you can find support built-in. -For instructions, read the appropiate section at: +For instructions, read the appropriate section at: https://clang.llvm.org/docs/ClangFormat.html diff --git a/Documentation/process/embargoed-hardware-issues.rst b/Documentation/process/embargoed-hardware-issues.rst index 43cdc67..6f8f36e 100644 --- a/Documentation/process/embargoed-hardware-issues.rst +++ b/Documentation/process/embargoed-hardware-issues.rst @@ -152,7 +152,7 @@ The disclosing party should provide a list of contacts for all other entities who have already been, or should be, informed about the issue. This serves several purposes: - - The list of disclosed entities allows communication accross the + - The list of disclosed entities allows communication across the industry, e.g. other OS vendors, HW vendors, etc. - The disclosed entities can be contacted to name experts who should -- 1.8.3.1
Linux 4.4.247
I'm announcing the release of the 4.4.247 kernel.
All users of the 4.4 kernel series must upgrade.
The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
Makefile |2 -
arch/x86/kernel/cpu/bugs.c|4 +-
arch/x86/xen/spinlock.c | 12 +++-
drivers/dma/pl330.c |2 -
drivers/hid/hid-cypress.c | 44 ++
drivers/hid/hid-ids.h |2 +
drivers/hid/hid-sensor-hub.c |3 +-
drivers/infiniband/hw/mthca/mthca_cq.c| 10 --
drivers/input/serio/i8042.c | 12 +++-
drivers/net/ethernet/broadcom/bnxt/bnxt.c |3 +-
drivers/nfc/s3fwrn5/i2c.c |4 +-
drivers/scsi/libiscsi.c | 23 ++-
drivers/scsi/ufs/ufshcd.c |6
drivers/target/iscsi/iscsi_target.c | 17 ---
drivers/usb/core/config.c | 11 +++
drivers/usb/core/devio.c |4 +-
drivers/usb/core/quirks.c | 38 +
drivers/usb/core/usb.h|3 ++
drivers/video/fbdev/hyperv_fb.c |7
fs/btrfs/inode.c | 41 ++-
fs/btrfs/qgroup.c |2 -
fs/btrfs/tests/inode-tests.c |1
fs/btrfs/volumes.c|7
fs/efivarfs/inode.c |2 +
fs/efivarfs/super.c |1
fs/proc/self.c|7
include/linux/usb/quirks.h|3 ++
include/scsi/libiscsi.h |3 ++
tools/perf/util/dwarf-aux.c |8 +
29 files changed, 233 insertions(+), 49 deletions(-)
Alan Stern (2):
USB: core: Change %pK for __user pointers to %px
USB: core: Fix regression in Hercules audio card
Anand K Mistry (1):
x86/speculation: Fix prctl() when spectre_v2_user={seccomp,prctl},ibpb
Ard Biesheuvel (1):
efivarfs: revert "fix memory leak in efivarfs_create()"
Brian Masney (1):
x86/xen: don't unbind uninitialized lock_kicker_irq
Dexuan Cui (1):
video: hyperv_fb: Fix the cache type when mapping the VRAM
Filipe Manana (1):
btrfs: fix lockdep splat when reading qgroup config on mount
Frank Yang (1):
HID: cypress: Support Varmilo Keyboards' media hotkeys
Greg Kroah-Hartman (1):
Linux 4.4.247
Hans de Goede (1):
Input: i8042 - allow insmod to succeed on devices without an i8042
controller
Jens Axboe (1):
proc: don't allow async path resolution of /proc/self components
Johan Hovold (1):
USB: core: add endpoint-blacklist quirk
Krzysztof Kozlowski (1):
nfc: s3fwrn5: use signed integer for parsing GPIO numbers
Lee Duncan (1):
scsi: libiscsi: Fix NOP race condition
Masami Hiramatsu (1):
perf probe: Fix to die_entrypc() returns error correctly
Michael Chan (1):
bnxt_en: Release PCI regions when DMA mask setup fails during probe.
Mike Christie (1):
scsi: target: iscsi: Fix cmd abort fabric stop race
Pablo Ceballos (1):
HID: hid-sensor-hub: Fix issue with devices with no report ID
Qu Wenruo (2):
btrfs: tree-checker: Enhance chunk checker to validate chunk profile
btrfs: inode: Verify inode mode to avoid NULL pointer dereference
Stanley Chu (1):
scsi: ufs: Fix race between shutdown and runtime resume flow
Sugar Zhang (1):
dmaengine: pl330: _prep_dma_memcpy: Fix wrong burst size
Xiongfeng Wang (1):
IB/mthca: fix return value of error branch in mthca_init_cq()
Zhang Changzhong (1):
bnxt_en: fix error return code in bnxt_init_board()
Re: Linux 4.4.247
diff --git a/Makefile b/Makefile
index c42ada4e8846..c493d3ae046f 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 246
+SUBLEVEL = 247
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 2c9a2992863b..ffc3bc8111b8 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -707,11 +707,13 @@ spectre_v2_user_select_mitigation(enum
spectre_v2_mitigation_cmd v2_cmd)
if (boot_cpu_has(X86_FEATURE_IBPB)) {
setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
+ spectre_v2_user_ibpb = mode;
switch (cmd) {
case SPECTRE_V2_USER_CMD_FORCE:
case SPECTRE_V2_USER_CMD_PRCTL_IBPB:
case SPECTRE_V2_USER_CMD_SECCOMP_IBPB:
static_branch_enable(_mm_always_ibpb);
+ spectre_v2_user_ibpb = SPECTRE_V2_USER_STRICT;
break;
case SPECTRE_V2_USER_CMD_PRCTL:
case SPECTRE_V2_USER_CMD_AUTO:
@@ -725,8 +727,6 @@ spectre_v2_user_select_mitigation(enum
spectre_v2_mitigation_cmd v2_cmd)
pr_info("mitigation: Enabling %s Indirect Branch Prediction
Barrier\n",
static_key_enabled(_mm_always_ibpb) ?
"always-on" : "conditional");
-
- spectre_v2_user_ibpb = mode;
}
/*
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 85872a08994a..e9fc0f7df0da 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -301,10 +301,20 @@ void xen_init_lock_cpu(int cpu)
void xen_uninit_lock_cpu(int cpu)
{
+ int irq;
+
if (!xen_pvspin)
return;
- unbind_from_irqhandler(per_cpu(lock_kicker_irq, cpu), NULL);
+ /*
+* When booting the kernel with 'mitigations=auto,nosmt', the secondary
+* CPUs are not activated, and lock_kicker_irq is not initialized.
+*/
+ irq = per_cpu(lock_kicker_irq, cpu);
+ if (irq == -1)
+ return;
+
+ unbind_from_irqhandler(irq, NULL);
per_cpu(lock_kicker_irq, cpu) = -1;
kfree(per_cpu(irq_name, cpu));
per_cpu(irq_name, cpu) = NULL;
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 9aa57b37381a..7f66ae1945b2 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2634,7 +2634,7 @@ pl330_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t
dst,
* If burst size is smaller than bus width then make sure we only
* transfer one at a time to avoid a burst stradling an MFIFO entry.
*/
- if (desc->rqcfg.brst_size * 8 < pl330->pcfg.data_bus_width)
+ if (burst * 8 < pl330->pcfg.data_bus_width)
desc->rqcfg.brst_len = 1;
desc->bytes_requested = len;
diff --git a/drivers/hid/hid-cypress.c b/drivers/hid/hid-cypress.c
index 1689568b597d..12c5d7c96527 100644
--- a/drivers/hid/hid-cypress.c
+++ b/drivers/hid/hid-cypress.c
@@ -26,19 +26,17 @@
#define CP_2WHEEL_MOUSE_HACK 0x02
#define CP_2WHEEL_MOUSE_HACK_ON0x04
+#define VA_INVAL_LOGICAL_BOUNDARY 0x08
+
/*
* Some USB barcode readers from cypress have usage min and usage max in
* the wrong order
*/
-static __u8 *cp_report_fixup(struct hid_device *hdev, __u8 *rdesc,
+static __u8 *cp_rdesc_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
{
- unsigned long quirks = (unsigned long)hid_get_drvdata(hdev);
unsigned int i;
- if (!(quirks & CP_RDESC_SWAPPED_MIN_MAX))
- return rdesc;
-
if (*rsize < 4)
return rdesc;
@@ -51,6 +49,40 @@ static __u8 *cp_report_fixup(struct hid_device *hdev, __u8
*rdesc,
return rdesc;
}
+static __u8 *va_logical_boundary_fixup(struct hid_device *hdev, __u8 *rdesc,
+ unsigned int *rsize)
+{
+ /*
+* Varmilo VA104M (with VID Cypress and device ID 07B1) incorrectly
+* reports Logical Minimum of its Consumer Control device as 572
+* (0x02 0x3c). Fix this by setting its Logical Minimum to zero.
+*/
+ if (*rsize == 25 &&
+ rdesc[0] == 0x05 && rdesc[1] == 0x0c &&
+ rdesc[2] == 0x09 && rdesc[3] == 0x01 &&
+ rdesc[6] == 0x19 && rdesc[7] == 0x00 &&
+ rdesc[11] == 0x16 && rdesc[12] == 0x3c && rdesc[13] ==
0x02) {
+ hid_info(hdev,
+"fixing up varmilo VA104M consumer control report
descriptor\n");
+ rdesc[12] = 0x00;
+ rdesc[13] = 0x00;
+ }
+ return rdesc;
+}
+
+static __u8 *cp_report_fixup(struct hid_device *hdev, __u8 *rdesc,
+ unsigned int *rsize)
+{
+ unsigned long quirks = (unsigned long)hid_get_drvdata(hdev);
+
+ if (quirks & CP_RDESC_SWAPPED_MIN_MAX)
+
[PATCH v3 1/1] kasan: fix object remain in offline per-cpu quarantine
We hit this issue in our internal test.
When enabling generic kasan, a kfree()'d object is put into per-cpu
quarantine first. If the cpu goes offline, object still remains in
the per-cpu quarantine. If we call kmem_cache_destroy() now, slub
will report "Objects remaining" error.
[ 74.982625]
=
[ 74.983380] BUG test_module_slab (Not tainted): Objects remaining in
test_module_slab on __kmem_cache_shutdown()
[ 74.984145]
-
[ 74.984145]
[ 74.984883] Disabling lock debugging due to kernel taint
[ 74.985561] INFO: Slab 0x(ptrval) objects=34 used=1
fp=0x(ptrval) flags=0x20010200
[ 74.986638] CPU: 3 PID: 176 Comm: cat Tainted: GB
5.10.0-rc1-7-g4525c8781ec0-dirty #10
[ 74.987262] Hardware name: linux,dummy-virt (DT)
[ 74.987606] Call trace:
[ 74.987924] dump_backtrace+0x0/0x2b0
[ 74.988296] show_stack+0x18/0x68
[ 74.988698] dump_stack+0xfc/0x168
[ 74.989030] slab_err+0xac/0xd4
[ 74.989346] __kmem_cache_shutdown+0x1e4/0x3c8
[ 74.989779] kmem_cache_destroy+0x68/0x130
[ 74.990176] test_version_show+0x84/0xf0
[ 74.990679] module_attr_show+0x40/0x60
[ 74.991218] sysfs_kf_seq_show+0x128/0x1c0
[ 74.991656] kernfs_seq_show+0xa0/0xb8
[ 74.992059] seq_read+0x1f0/0x7e8
[ 74.992415] kernfs_fop_read+0x70/0x338
[ 74.993051] vfs_read+0xe4/0x250
[ 74.993498] ksys_read+0xc8/0x180
[ 74.993825] __arm64_sys_read+0x44/0x58
[ 74.994203] el0_svc_common.constprop.0+0xac/0x228
[ 74.994708] do_el0_svc+0x38/0xa0
[ 74.995088] el0_sync_handler+0x170/0x178
[ 74.995497] el0_sync+0x174/0x180
[ 74.996050] INFO: Object 0x(ptrval) @offset=15848
[ 74.996752] INFO: Allocated in test_version_show+0x98/0xf0 age=8188 cpu=6
pid=172
[ 75.000802] stack_trace_save+0x9c/0xd0
[ 75.002420] set_track+0x64/0xf0
[ 75.002770] alloc_debug_processing+0x104/0x1a0
[ 75.003171] ___slab_alloc+0x628/0x648
[ 75.004213] __slab_alloc.isra.0+0x2c/0x58
[ 75.004757] kmem_cache_alloc+0x560/0x588
[ 75.005376] test_version_show+0x98/0xf0
[ 75.005756] module_attr_show+0x40/0x60
[ 75.007035] sysfs_kf_seq_show+0x128/0x1c0
[ 75.007433] kernfs_seq_show+0xa0/0xb8
[ 75.007800] seq_read+0x1f0/0x7e8
[ 75.008128] kernfs_fop_read+0x70/0x338
[ 75.008507] vfs_read+0xe4/0x250
[ 75.008990] ksys_read+0xc8/0x180
[ 75.009462] __arm64_sys_read+0x44/0x58
[ 75.010085] el0_svc_common.constprop.0+0xac/0x228
[ 75.011006] kmem_cache_destroy test_module_slab: Slab cache still has objects
Register a cpu hotplug function to remove all objects in the offline
per-cpu quarantine when cpu is going offline. Set a per-cpu variable
to indicate this cpu is offline.
Signed-off-by: Kuan-Ying Lee
Suggested-by: Dmitry Vyukov
Reported-by: Guangye Yang
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
Cc: Andrew Morton
Cc: Matthias Brugger
---
mm/kasan/quarantine.c | 40
1 file changed, 40 insertions(+)
diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
index 4c5375810449..cac7c617df72 100644
--- a/mm/kasan/quarantine.c
+++ b/mm/kasan/quarantine.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "../slab.h"
#include "kasan.h"
@@ -43,6 +44,7 @@ struct qlist_head {
struct qlist_node *head;
struct qlist_node *tail;
size_t bytes;
+ bool offline;
};
#define QLIST_INIT { NULL, NULL, 0 }
@@ -188,6 +190,11 @@ void quarantine_put(struct kasan_free_meta *info, struct
kmem_cache *cache)
local_irq_save(flags);
q = this_cpu_ptr(_quarantine);
+ if (q->offline) {
+ qlink_free(>quarantine_link, cache);
+ local_irq_restore(flags);
+ return;
+ }
qlist_put(q, >quarantine_link, cache->size);
if (unlikely(q->bytes > QUARANTINE_PERCPU_SIZE)) {
qlist_move_all(q, );
@@ -328,3 +335,36 @@ void quarantine_remove_cache(struct kmem_cache *cache)
synchronize_srcu(_cache_srcu);
}
+
+static int kasan_cpu_online(unsigned int cpu)
+{
+ this_cpu_ptr(_quarantine)->offline = false;
+ return 0;
+}
+
+static int kasan_cpu_offline(unsigned int cpu)
+{
+ struct qlist_head *q;
+
+ q = this_cpu_ptr(_quarantine);
+ /* Ensure the ordering between the writing to q->offline and
+* qlist_free_all. Otherwise, cpu_quarantine may be corrupted
+* by interrupt.
+*/
+ WRITE_ONCE(q->offline, true);
+ barrier();
+ qlist_free_all(q, NULL);
+ return 0;
+}
+
+static int __init kasan_cpu_quarantine_init(void)
+{
+ int ret = 0;
+
+ ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "mm/kasan:online",
+ kasan_cpu_online, kasan_cpu_offline);
+ if (ret < 0)
+ pr_err("kasan cpu quarantine
Re: [GIT pull] locking/urgent for v5.10-rc6
On Tue, Dec 01, 2020 at 11:45:25AM -0800, Linus Torvalds wrote: > On Mon, Nov 30, 2020 at 11:56 PM Peter Zijlstra wrote: > > > > So even if an architecture needs to enable interrupts on idle, we need > > it disabled again when coming out. So we might as well have the arch > > idle routine then be: STI; HLT; CLI; because then architectures than can > > idle with interrupts disabled can avoid mucking about with the interrupt > > state entirely. > > But that's not what the code is doing. > > Go look at it. > > It does sti;hlt;cli;pushf;cli;sti. > > All for no good reason - because the code is structured so that even > if all the tracking and lockdep is disabled, the pointless "let's > protect the tracking from interrupts" is still there. > > See what I am complaining about? Absolutely. default_idle() arch_cpu_idle() sti; hlt; cli; rcu_idle_exit() pushf; cli; rcu_eqs_exit(false); popf; sti; is what it currently looks like, and that's completely insane, no argument. What I would like to end up with is: default_idle() arch_cpu_idle() sti; hlt; cli rcu_idle_exit() rcu_eqs_exit(false); sti; Which would allow architectures that can idle with IRQs disabled to do so. But that needs a little more work: - make arch_cpu_idle() IRQ invariant (we enter and exit with IRQs off) - make cpuidle drivers do similar - audit all rcu_idle_exit() callers and remove save/restore
[PATCH] media: vidtv: fix kernel-doc markups
Some functions has a different name between their prototypes and the corresponding kernel-doc markups. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/test-drivers/vidtv/vidtv_psi.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/test-drivers/vidtv/vidtv_psi.h b/drivers/media/test-drivers/vidtv/vidtv_psi.h index 340c9fb8d583..6651cc91bda1 100644 --- a/drivers/media/test-drivers/vidtv/vidtv_psi.h +++ b/drivers/media/test-drivers/vidtv/vidtv_psi.h @@ -420,7 +420,7 @@ void vidtv_psi_desc_assign(struct vidtv_psi_desc **to, struct vidtv_psi_desc *desc); /** - * vidtv_psi_pmt_desc_assign - Assigns a descriptor loop at some point in a PMT section. + * vidtv_pmt_desc_assign - Assigns a descriptor loop at some point in a PMT section. * @pmt: The PMT section that will contain the descriptor loop * @to: Where in the PMT to assign this descriptor loop to * @desc: The descriptor loop that will be assigned. @@ -434,7 +434,7 @@ void vidtv_pmt_desc_assign(struct vidtv_psi_table_pmt *pmt, struct vidtv_psi_desc *desc); /** - * vidtv_psi_sdt_desc_assign - Assigns a descriptor loop at some point in a SDT. + * vidtv_sdt_desc_assign - Assigns a descriptor loop at some point in a SDT. * @sdt: The SDT that will contain the descriptor loop * @to: Where in the PMT to assign this descriptor loop to * @desc: The descriptor loop that will be assigned. @@ -474,7 +474,7 @@ void vidtv_psi_pmt_stream_assign(struct vidtv_psi_table_pmt *pmt, struct vidtv_psi_desc *vidtv_psi_desc_clone(struct vidtv_psi_desc *desc); /** - * vidtv_psi_create_sec_for_each_pat_entry - Create a PMT section for each + * vidtv_psi_pmt_create_sec_for_each_pat_entry - Create a PMT section for each * program found in the PAT * @pat: The PAT to look for programs. * @pcr_pid: packet ID for the PCR to be used for the program described in this -- 2.28.0
[PATCH] igc: Report speed and duplex as unknown when device is runtime suspended
Similar to commit 165ae7a8feb5 ("igb: Report speed and duplex as unknown
when device is runtime suspended"), if we try to read speed and duplex
sysfs while the device is runtime suspeneded, igc will complain and
stops working:
[ 123.449883] igc :03:00.0 enp3s0: PCIe link lost, device now detached
[ 123.450052] BUG: kernel NULL pointer dereference, address: 0008
[ 123.450056] #PF: supervisor read access in kernel mode
[ 123.450058] #PF: error_code(0x) - not-present page
[ 123.450059] PGD 0 P4D 0
[ 123.450064] Oops: [#1] SMP NOPTI
[ 123.450068] CPU: 0 PID: 2525 Comm: udevadm Tainted: G U W OE
5.10.0-1002-oem #2+rkl2-Ubuntu
[ 123.450078] RIP: 0010:igc_rd32+0x1c/0x90 [igc]
[ 123.450080] Code: c0 5d c3 b8 fd ff ff ff c3 0f 1f 44 00 00 0f 1f 44 00 00
55 89 f0 48 89 e5 41 56 41 55 41 54 49 89 c4 53 48 8b 57 08 48 01 d0 <44> 8b 28
41 83 fd ff 74 0c 5b 44 89 e8 41 5c 41 5d 4
[ 123.450083] RSP: 0018:b0d100d6fcc0 EFLAGS: 00010202
[ 123.450085] RAX: 0008 RBX: b0d100d6fd30 RCX:
[ 123.450087] RDX: RSI: 0008 RDI: 945a12716c10
[ 123.450089] RBP: b0d100d6fce0 R08: 945a12716550 R09: 945a09874000
[ 123.450090] R10: R11: R12: 0008
[ 123.450092] R13: 945a12716000 R14: 945a037da280 R15: 945a037da290
[ 123.450094] FS: 7f3b34c868c0() GS:945b8920()
knlGS:
[ 123.450096] CS: 0010 DS: ES: CR0: 80050033
[ 123.450098] CR2: 0008 CR3: 0001144de006 CR4: 00770ef0
[ 123.450100] PKRU: 5554
[ 123.450101] Call Trace:
[ 123.450111] igc_ethtool_get_link_ksettings+0xd6/0x1b0 [igc]
[ 123.450118] __ethtool_get_link_ksettings+0x71/0xb0
[ 123.450123] duplex_show+0x74/0xc0
[ 123.450129] dev_attr_show+0x1d/0x40
[ 123.450134] sysfs_kf_seq_show+0xa1/0x100
[ 123.450137] kernfs_seq_show+0x27/0x30
[ 123.450142] seq_read+0xb7/0x400
[ 123.450148] ? common_file_perm+0x72/0x170
[ 123.450151] kernfs_fop_read+0x35/0x1b0
[ 123.450155] vfs_read+0xb5/0x1b0
[ 123.450157] ksys_read+0x67/0xe0
[ 123.450160] __x64_sys_read+0x1a/0x20
[ 123.450164] do_syscall_64+0x38/0x90
[ 123.450168] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 123.450170] RIP: 0033:0x7f3b351fe142
[ 123.450173] Code: c0 e9 c2 fe ff ff 50 48 8d 3d 3a ca 0a 00 e8 f5 19 02 00
0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00
f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
[ 123.450174] RSP: 002b:7fffef2ec138 EFLAGS: 0246 ORIG_RAX:
[ 123.450177] RAX: ffda RBX: RCX: 7f3b351fe142
[ 123.450179] RDX: 1001 RSI: 5644c047f070 RDI: 0003
[ 123.450180] RBP: 7fffef2ec340 R08: 5644c047f070 R09: 7f3b352d9320
[ 123.450182] R10: 5644c047c010 R11: 0246 R12: 5644c047cbf0
[ 123.450184] R13: 5644c047e6d0 R14: 0003 R15: 7fffef2ec140
[ 123.450189] Modules linked in: rfcomm ccm cmac algif_hash algif_skcipher
af_alg bnep toshiba_acpi industrialio toshiba_haps hp_accel lis3lv02d btusb
btrtl btbcm btintel bluetooth ecdh_generic ecc joydev input_leds nls_iso8859_1
snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common
snd_soc_hdac_hda snd_hda_codec_hdmi snd_sof_xtensa_dsp snd_sof_intel_hda
snd_sof snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi
snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel
snd_intel_dspcfg soundwire_intel soundwire_generic_allocation soundwire_cadence
snd_hda_codec snd_hda_core ath10k_pci snd_hwdep intel_rapl_msr
intel_rapl_common ath10k_core soundwire_bus snd_soc_core x86_pkg_temp_thermal
ath intel_powerclamp snd_compress ac97_bus snd_pcm_dmaengine mac80211 snd_pcm
coretemp snd_seq_midi snd_seq_midi_event snd_rawmidi kvm_intel cfg80211 snd_seq
snd_seq_device snd_timer mei_hdcp kvm libarc4 snd crct10dif_pclmul
ghash_clmulni_intel aesni_intel mei_me dell_wmi
[ 123.450266] dell_smbios soundcore sparse_keymap dcdbas crypto_simd cryptd
mei dell_uart_backlight glue_helper ee1004 wmi_bmof intel_wmi_thunderbolt
dell_wmi_descriptor mac_hid efi_pstore acpi_pad acpi_tad intel_cstate
sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs
blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear
dm_mirror dm_region_hash dm_log hid_generic usbhid hid i915 i2c_algo_bit
drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec crc32_pclmul
rc_core drm intel_lpss_pci i2c_i801 ahci igc intel_lpss i2c_smbus idma64
xhci_pci libahci virt_dma xhci_pci_renesas wmi video pinctrl_tigerlake
[ 123.450335] CR2: 0008
[ 123.450338] ---[ end trace 9f731e38b53c35cc ]---
The more generic approach will be wrap get_link_ksettings() with begin()
and complete()
Re: [PATCH drm/hisilicon v2 1/4] drm/hisilicon: Assgin local variable to drm_device
Hi
Am 02.12.20 um 03:54 schrieb tiantao (H):
在 2020/12/2 10:06, tiantao (H) 写道:
在 2020/12/1 21:44, Thomas Zimmermann 写道:
Hi
Am 01.12.20 um 14:05 schrieb tiantao (H):
在 2020/12/1 20:36, Thomas Zimmermann 写道:
Hi
Am 01.12.20 um 13:26 schrieb tiantao (H):
在 2020/12/1 20:17, Thomas Zimmermann 写道:
Hi
Am 01.12.20 um 12:55 schrieb Tian Tao:
Assign local variable to struct drm_device *dev because they are
used multiple times within a function.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 30
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 8 ---
5 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index ea962ac..096eea9 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -499,7 +499,7 @@ static const struct drm_crtc_helper_funcs
hibmc_crtc_helper_funcs = {
int hibmc_de_init(struct hibmc_drm_private *priv)
{
- struct drm_device *dev = priv->dev;
+ struct drm_device *dev = >dev;
struct drm_crtc *crtc = >crtc;
struct drm_plane *plane = >primary_plane;
int ret;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index d845657..dd9fadc 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -79,31 +79,32 @@ static const struct dev_pm_ops hibmc_pm_ops = {
static int hibmc_kms_init(struct hibmc_drm_private *priv)
{
+ struct drm_device *dev = >dev;
int ret;
- drm_mode_config_init(priv->dev);
+ drm_mode_config_init(dev);
priv->mode_config_initialized = true;
- priv->dev->mode_config.min_width = 0;
- priv->dev->mode_config.min_height = 0;
- priv->dev->mode_config.max_width = 1920;
- priv->dev->mode_config.max_height = 1200;
+ dev->mode_config.min_width = 0;
+ dev->mode_config.min_height = 0;
+ dev->mode_config.max_width = 1920;
+ dev->mode_config.max_height = 1200;
- priv->dev->mode_config.fb_base = priv->fb_base;
- priv->dev->mode_config.preferred_depth = 32;
- priv->dev->mode_config.prefer_shadow = 1;
+ dev->mode_config.fb_base = priv->fb_base;
+ dev->mode_config.preferred_depth = 32;
+ dev->mode_config.prefer_shadow = 1;
- priv->dev->mode_config.funcs = (void *)_mode_funcs;
+ dev->mode_config.funcs = (void *)_mode_funcs;
ret = hibmc_de_init(priv);
if (ret) {
- drm_err(priv->dev, "failed to init de: %d\n", ret);
+ drm_err(dev, "failed to init de: %d\n", ret);
return ret;
}
ret = hibmc_vdac_init(priv);
if (ret) {
- drm_err(priv->dev, "failed to init vdac: %d\n", ret);
+ drm_err(dev, "failed to init vdac: %d\n", ret);
return ret;
}
@@ -113,7 +114,7 @@ static int hibmc_kms_init(struct
hibmc_drm_private *priv)
static void hibmc_kms_fini(struct hibmc_drm_private *priv)
{
if (priv->mode_config_initialized) {
- drm_mode_config_cleanup(priv->dev);
+ drm_mode_config_cleanup(>dev);
priv->mode_config_initialized = false;
}
}
@@ -202,7 +203,7 @@ static void hibmc_hw_config(struct
hibmc_drm_private *priv)
static int hibmc_hw_map(struct hibmc_drm_private *priv)
{
- struct drm_device *dev = priv->dev;
+ struct drm_device *dev = >dev;
struct pci_dev *pdev = dev->pdev;
resource_size_t addr, size, ioaddr, iosize;
@@ -258,7 +259,7 @@ static int hibmc_unload(struct drm_device *dev)
static int hibmc_load(struct drm_device *dev)
{
- struct hibmc_drm_private *priv;
+ struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
int ret;
priv = drmm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -267,7 +268,6 @@ static int hibmc_load(struct drm_device *dev)
return -ENOMEM;
}
dev->dev_private = priv;
- priv->dev = dev;
I'm sure this either does not build or does not work. There's a
call to drm_dev_alloc(), which initialized the DRM device. You
need to assign the returned device here. The embedding of dev
only work after you switched to devm_drm_dev_alloc() in the next
patch.
For the patch at hand, just keep struct hibmc_drm_private.dev as
a pointer and you should be fine.
Changing drm_device *dev to drm_device dev and using
devm_drm_dev_alloc does not easily split into two patches.
The patch does not compile well on its own, but it will compile
fine with patch #2.
Can patch #1 and patch #2 be combined into a single patch,just
like V1.
Most of the code in this patch does
struct drm_device *dev = >dev;
to get dev as a local variable. Why don't you do
struct drm_device *dev
orion-nand: uncorrectable ECC error on v5.10-rc6
Hi, I've just booted v5.10-rc6 on a kirkwood based board (which uses the orion-nand driver) and I get the following errors reported. I haven't started bisecting yet but v5.7.19 mounts the nand flash without any issue. ubi0: attaching mtd0 __nand_correct_data: uncorrectable ECC error ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry __nand_correct_data: uncorrectable ECC error ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry __nand_correct_data: uncorrectable ECC error ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry __nand_correct_data: uncorrectable ECC error ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read 64 bytes CPU: 0 PID: 101 Comm: ubiattach Not tainted 5.10.0-rc6+ #1 Hardware name: Marvell Kirkwood (Flattened Device Tree) [<8010ca64>] (unwind_backtrace) from [<80109bd0>] (show_stack+0x10/0x14) [<80109bd0>] (show_stack) from [<8045f10c>] (ubi_io_read+0x184/0x304) [<8045f10c>] (ubi_io_read) from [<8045f4ac>] (ubi_io_read_ec_hdr+0x44/0x240) [<8045f4ac>] (ubi_io_read_ec_hdr) from [<80464db0>] (ubi_attach+0x178/0x15fc) [<80464db0>] (ubi_attach) from [<80458d8c>] (ubi_attach_mtd_dev+0x538/0xb48) [<80458d8c>] (ubi_attach_mtd_dev) from [<8045a114>] (ctrl_cdev_ioctl+0x170/0x1e0) [<8045a114>] (ctrl_cdev_ioctl) from [<80203094>] (sys_ioctl+0x1f8/0x990) [<80203094>] (sys_ioctl) from [<80100060>] (ret_fast_syscall+0x0/0x50) Exception stack(0x87633fa8 to 0x87633ff0) 3fa0: 0003 7e9b0c30 0003 40186f40 7e9b0c30 3fc0: 0003 7e9b0c30 000148f8 0036 00014770 00013f90 76f3dfa4 3fe0: 76e936f0 7e9b0c1c 00011f68 76e936fc
[PATCH] Documentation: fix typos in process/kernel-docs.rst
Fix two typos in kernel-docs.rst Signed-off-by: Andrew Klychkov --- Documentation/process/kernel-docs.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst index 64786e5..22d9ace 100644 --- a/Documentation/process/kernel-docs.rst +++ b/Documentation/process/kernel-docs.rst @@ -90,7 +90,7 @@ On-line docs :Date: 2008 :Keywords: patches, review process, types of submissions, basic rules, case studies :Description: This paper gives several experience values on what types of patches -there are and how likley they get merged. +there are and how likely they get merged. :Abstract: [...]. This paper examines some common problems for submitting larger changes and some strategies to avoid problems. @@ -328,7 +328,7 @@ On-line docs block devices, hardware interrupts, scsi, DMA, access to user memory, memory allocation, timers. :Description: A guide designed to help you get up to speed on the -concepts that are not intuitevly obvious, and to document the internal +concepts that are not intuitively obvious, and to document the internal structures of Linux. * Title: **Dynamic Kernels: Modularized Device Drivers** -- 1.8.3.1
Re: [PATCH 4.19 00/57] 4.19.161-rc1 review
On Tue, Dec 01, 2020 at 04:59:24PM +0100, Pavel Machek wrote: > Hi! > > > This is the start of the stable review cycle for the 4.19.161 release. > > There are 57 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, 03 Dec 2020 08:46:29 +. > > Anything received after that time might be too late. > > No problems detected during testing: > > https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.19.y > > Tested-by: Pavel Machek (CIP) Thanks for testing 2 of these and letting me know. greg k-h
[PATCH v2 1/3] firmware: xilinx: Remove additional newline
This additional newline is useless and also reported by checkpatch
--strict.
Signed-off-by: Michal Simek
---
(no changes since v1)
include/linux/firmware/xlnx-zynqmp.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/firmware/xlnx-zynqmp.h
b/include/linux/firmware/xlnx-zynqmp.h
index f84244ea633b..0db9005782d6 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -316,7 +316,6 @@ struct zynqmp_pm_query_data {
u32 arg3;
};
-
int zynqmp_pm_invoke_fn(u32 pm_api_id, u32 arg0, u32 arg1,
u32 arg2, u32 arg3, u32 *ret_payload);
--
2.29.2
[PATCH v5 4/5] perf metric: Add utilities to work on ids map.
Add utilities to new/free an ids hashmap, as well as to union. Add
testing of the union. Unioning hashmaps will be used when parsing the
metric, if a value is known then the hashmap is unnecessary, otherwise
we need to union together all the event ids to compute their values for
reporting.
Signed-off-by: Ian Rogers
---
tools/perf/tests/expr.c | 47 ++
tools/perf/util/expr.c | 87 +++--
tools/perf/util/expr.h | 9 +
3 files changed, 139 insertions(+), 4 deletions(-)
diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
index 7ccb97c73347..1c881bea7fca 100644
--- a/tools/perf/tests/expr.c
+++ b/tools/perf/tests/expr.c
@@ -6,6 +6,51 @@
#include
#include
+static int test_ids_union(void)
+{
+ struct hashmap *ids1, *ids2;
+
+ /* Empty union. */
+ ids1 = ids__new();
+ TEST_ASSERT_VAL("ids__new", ids1);
+ ids2 = ids__new();
+ TEST_ASSERT_VAL("ids__new", ids2);
+
+ ids1 = ids__union(ids1, ids2);
+ TEST_ASSERT_EQUAL("union", (int)hashmap__size(ids1), 0);
+
+ /* Union {foo, bar} against {}. */
+ ids2 = ids__new();
+ TEST_ASSERT_VAL("ids__new", ids2);
+
+ TEST_ASSERT_EQUAL("ids__insert", ids__insert(ids1, strdup("foo"),
NULL), 0);
+ TEST_ASSERT_EQUAL("ids__insert", ids__insert(ids1, strdup("bar"),
NULL), 0);
+
+ ids1 = ids__union(ids1, ids2);
+ TEST_ASSERT_EQUAL("union", (int)hashmap__size(ids1), 2);
+
+ /* Union {foo, bar} against {foo}. */
+ ids2 = ids__new();
+ TEST_ASSERT_VAL("ids__new", ids2);
+ TEST_ASSERT_EQUAL("ids__insert", ids__insert(ids2, strdup("foo"),
NULL), 0);
+
+ ids1 = ids__union(ids1, ids2);
+ TEST_ASSERT_EQUAL("union", (int)hashmap__size(ids1), 2);
+
+ /* Union {foo, bar} against {bar,baz}. */
+ ids2 = ids__new();
+ TEST_ASSERT_VAL("ids__new", ids2);
+ TEST_ASSERT_EQUAL("ids__insert", ids__insert(ids2, strdup("bar"),
NULL), 0);
+ TEST_ASSERT_EQUAL("ids__insert", ids__insert(ids2, strdup("baz"),
NULL), 0);
+
+ ids1 = ids__union(ids1, ids2);
+ TEST_ASSERT_EQUAL("union", (int)hashmap__size(ids1), 3);
+
+ ids__free(ids1);
+
+ return 0;
+}
+
static int test(struct expr_parse_ctx *ctx, const char *e, double val2)
{
double val;
@@ -24,6 +69,8 @@ int test__expr(struct test *t __maybe_unused, int subtest
__maybe_unused)
int ret;
struct expr_parse_ctx *ctx;
+ TEST_ASSERT_EQUAL("ids_union", test_ids_union(), 0);
+
ctx = expr__ctx_new();
TEST_ASSERT_VAL("expr__ctx_new", ctx);
expr__add_id_val(ctx, strdup("FOO"), 1);
diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
index a248d14882cc..1adb6cd202e0 100644
--- a/tools/perf/util/expr.c
+++ b/tools/perf/util/expr.c
@@ -59,8 +59,48 @@ static bool key_equal(const void *key1, const void *key2,
return !strcmp((const char *)key1, (const char *)key2);
}
-/* Caller must make sure id is allocated */
-int expr__add_id(struct expr_parse_ctx *ctx, const char *id)
+struct hashmap *ids__new(void)
+{
+ return hashmap__new(key_hash, key_equal, NULL);
+}
+
+void ids__free(struct hashmap *ids)
+{
+ struct hashmap_entry *cur;
+ size_t bkt;
+
+ if (ids == NULL)
+ return;
+
+#ifdef PARSER_DEBUG
+ fprintf(stderr, "freeing ids: ");
+ ids__print(ids);
+ fprintf(stderr, "\n");
+#endif
+
+ hashmap__for_each_entry(ids, cur, bkt) {
+ free((char *)cur->key);
+ free(cur->value);
+ }
+
+ hashmap__free(ids);
+}
+
+void ids__print(struct hashmap *ids)
+{
+ size_t bkt;
+ struct hashmap_entry *cur;
+
+ if (!ids)
+ return;
+
+ hashmap__for_each_entry(ids, cur, bkt) {
+ fprintf(stderr, "key:%s, ", (const char *)cur->key);
+ }
+}
+
+int ids__insert(struct hashmap *ids, const char *id,
+ struct expr_id *parent)
{
struct expr_id_data *data_ptr = NULL, *old_data = NULL;
char *old_key = NULL;
@@ -70,10 +110,10 @@ int expr__add_id(struct expr_parse_ctx *ctx, const char
*id)
if (!data_ptr)
return -ENOMEM;
- data_ptr->parent = ctx->parent;
+ data_ptr->parent = parent;
data_ptr->kind = EXPR_ID_DATA__PARENT;
- ret = hashmap__set(ctx->ids, id, data_ptr,
+ ret = hashmap__set(ids, id, data_ptr,
(const void **)_key, (void **)_data);
if (ret)
free(data_ptr);
@@ -82,6 +122,45 @@ int expr__add_id(struct expr_parse_ctx *ctx, const char *id)
return ret;
}
+struct hashmap *ids__union(struct hashmap *ids1, struct hashmap *ids2)
+{
+ size_t bkt;
+ struct hashmap_entry *cur;
+ int ret;
+ struct expr_id_data *old_data = NULL;
+ char *old_key = NULL;
+
+ if (!ids1)
+ return ids2;
+
+ if (!ids2)
+ return
[PATCH v5 5/5] perf metric: Don't compute unused events.
For a metric like:
EVENT1 if #smt_on else EVENT2
currently EVENT1 and EVENT2 will be measured and then when the metric is
reported EVENT1 or EVENT2 will be printed depending on the value from
smt_on() during the expr parsing. Computing both events is unnecessary and
can lead to multiplexing as discussed in this thread:
https://lore.kernel.org/lkml/20201110100346.2527031-1-irog...@google.com/
This change modifies the expression parsing code by:
- getting rid of the "other" parsing and introducing a boolean argument
to say whether ids should be computed or not.
- expressions are changed so that a pair of value and ids are returned.
- when computing the metric value the ids are unused.
- when computing the ids, constant values and smt_on are assigned to
the value.
- If the value is from an event ID then the event is added to the ids
hashmap and the value set to bottom (encoded as NAN).
- Typically operators union IDs for their inputs and set the value to
bottom, however, if the inputs are constant then these are computed and
propagated as the value.
- If the input is constant to certain operators like:
IDS1 if CONST else IDS2
then the result will be either IDS1 or IDS2 depending on CONST (which
may be evaluated from an entire expression), and so IDS1 or IDS2 may
be discarded avoiding events from being programmed.
- The ids at the end of parsing are added to the context.
Signed-off-by: Ian Rogers
---
tools/perf/tests/expr.c | 17 ++
tools/perf/util/expr.c | 9 +-
tools/perf/util/expr.h | 1 -
tools/perf/util/expr.l | 9 --
tools/perf/util/expr.y | 340 ++--
5 files changed, 282 insertions(+), 94 deletions(-)
diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
index 1c881bea7fca..5cab5960b257 100644
--- a/tools/perf/tests/expr.c
+++ b/tools/perf/tests/expr.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#include "util/debug.h"
#include "util/expr.h"
+#include "util/smt.h"
#include "tests.h"
#include
#include
@@ -132,6 +133,22 @@ int test__expr(struct test *t __maybe_unused, int subtest
__maybe_unused)
TEST_ASSERT_VAL("find ids", hashmap__find(ctx->ids, "EVENT2,param=3/",
(void **)_ptr));
+ /* Only EVENT1 or EVENT2 need be measured depending on the value of
smt_on. */
+ expr__ctx_clear(ctx);
+ TEST_ASSERT_VAL("find ids",
+ expr__find_ids("EVENT1 if #smt_on else EVENT2",
+ NULL, ctx, 0) == 0);
+ TEST_ASSERT_VAL("find ids", hashmap__size(ctx->ids) == 1);
+ TEST_ASSERT_VAL("find ids", hashmap__find(ctx->ids,
+ smt_on() ? "EVENT1" :
"EVENT2",
+ (void **)_ptr));
+
+ /* The expression is a constant 1.0 without needing to evaluate EVENT1.
*/
+ expr__ctx_clear(ctx);
+ TEST_ASSERT_VAL("find ids",
+ expr__find_ids("1.0 if EVENT1 > 100.0 else 1.0",
+ NULL, ctx, 0) == 0);
+ TEST_ASSERT_VAL("find ids", hashmap__size(ctx->ids) == 0);
expr__ctx_free(ctx);
return 0;
diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
index 1adb6cd202e0..28aaa50c6c68 100644
--- a/tools/perf/util/expr.c
+++ b/tools/perf/util/expr.c
@@ -329,10 +329,9 @@ void expr__ctx_free(struct expr_parse_ctx *ctx)
static int
__expr__parse(double *val, struct expr_parse_ctx *ctx, const char *expr,
- int start, int runtime)
+ bool compute_ids, int runtime)
{
struct expr_scanner_ctx scanner_ctx = {
- .start_token = start,
.runtime = runtime,
};
YY_BUFFER_STATE buffer;
@@ -352,7 +351,7 @@ __expr__parse(double *val, struct expr_parse_ctx *ctx,
const char *expr,
expr_set_debug(1, scanner);
#endif
- ret = expr_parse(val, ctx, scanner);
+ ret = expr_parse(val, ctx, compute_ids, scanner);
expr__flush_buffer(buffer, scanner);
expr__delete_buffer(buffer, scanner);
@@ -363,13 +362,13 @@ __expr__parse(double *val, struct expr_parse_ctx *ctx,
const char *expr,
int expr__parse(double *final_val, struct expr_parse_ctx *ctx,
const char *expr, int runtime)
{
- return __expr__parse(final_val, ctx, expr, EXPR_PARSE, runtime) ? -1 :
0;
+ return __expr__parse(final_val, ctx, expr, /*compute_ids=*/false,
runtime) ? -1 : 0;
}
int expr__find_ids(const char *expr, const char *one,
struct expr_parse_ctx *ctx, int runtime)
{
- int ret = __expr__parse(NULL, ctx, expr, EXPR_OTHER, runtime);
+ int ret = __expr__parse(NULL, ctx, expr, /*compute_ids=*/true, runtime);
if (one)
expr__del_id(ctx, one);
diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
index 62d3ae5ddfba..cefeb2c8d85e 100644
---
[PATCH v5 2/5] perf metric: Use NAN for missing event IDs.
If during computing a metric an event (id) is missing the parsing
aborts. A later patch will make it so that events that aren't used in
the output are deliberately omitted, in which case we don't want the
abort. Modify the missing ID case to report NAN for these cases.
Signed-off-by: Ian Rogers
---
tools/perf/util/expr.y | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/expr.y b/tools/perf/util/expr.y
index b2ada8f8309a..41c9cd4efadd 100644
--- a/tools/perf/util/expr.y
+++ b/tools/perf/util/expr.y
@@ -1,6 +1,7 @@
/* Simple expression parser */
%{
#define YYDEBUG 1
+#include
#include
#include "util.h"
#include "util/debug.h"
@@ -88,12 +89,10 @@ expr: NUMBER
| ID{
struct expr_id_data *data;
- if (expr__resolve_id(ctx, $1, )) {
- free($1);
- YYABORT;
- }
+ $$ = NAN;
+ if (expr__resolve_id(ctx, $1, ) ==
0)
+ $$ = expr_id_data__value(data);
- $$ = expr_id_data__value(data);
free($1);
}
| expr '|' expr { $$ = (long)$1 | (long)$3; }
--
2.29.2.454.gaff20da3a2-goog
[PATCH v5 1/5] perf metric: Restructure struct expr_parse_ctx.
A later change to parsing the ids out (in expr__find_other) will
potentially drop hashmaps and so it is more convenient to move
expr_parse_ctx to have a hashmap pointer rather than a struct value. As
this pointer must be freed, rather than just going out of scope,
add expr__ctx_new and expr__ctx_free to manage expr_parse_ctx memory.
Adjust use of struct expr_parse_ctx accordingly.
Signed-off-by: Ian Rogers
---
tools/perf/tests/expr.c | 81 ++-
tools/perf/tests/pmu-events.c | 37 +---
tools/perf/util/expr.c| 38
tools/perf/util/expr.h| 5 ++-
tools/perf/util/metricgroup.c | 44 ++-
tools/perf/util/stat-shadow.c | 50 +
6 files changed, 151 insertions(+), 104 deletions(-)
diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
index 4d01051951cd..b0a3b5fd0c00 100644
--- a/tools/perf/tests/expr.c
+++ b/tools/perf/tests/expr.c
@@ -22,67 +22,70 @@ int test__expr(struct test *t __maybe_unused, int subtest
__maybe_unused)
const char *p;
double val;
int ret;
- struct expr_parse_ctx ctx;
+ struct expr_parse_ctx *ctx;
- expr__ctx_init();
- expr__add_id_val(, strdup("FOO"), 1);
- expr__add_id_val(, strdup("BAR"), 2);
+ ctx = expr__ctx_new();
+ TEST_ASSERT_VAL("expr__ctx_new", ctx);
+ expr__add_id_val(ctx, strdup("FOO"), 1);
+ expr__add_id_val(ctx, strdup("BAR"), 2);
- ret = test(, "1+1", 2);
- ret |= test(, "FOO+BAR", 3);
- ret |= test(, "(BAR/2)%2", 1);
- ret |= test(, "1 - -4", 5);
- ret |= test(, "(FOO-1)*2 + (BAR/2)%2 - -4", 5);
- ret |= test(, "1-1 | 1", 1);
- ret |= test(, "1-1 & 1", 0);
- ret |= test(, "min(1,2) + 1", 2);
- ret |= test(, "max(1,2) + 1", 3);
- ret |= test(, "1+1 if 3*4 else 0", 2);
- ret |= test(, "1.1 + 2.1", 3.2);
- ret |= test(, ".1 + 2.", 2.1);
- ret |= test(, "d_ratio(1, 2)", 0.5);
- ret |= test(, "d_ratio(2.5, 0)", 0);
- ret |= test(, "1.1 < 2.2", 1);
- ret |= test(, "2.2 > 1.1", 1);
- ret |= test(, "1.1 < 1.1", 0);
- ret |= test(, "2.2 > 2.2", 0);
- ret |= test(, "2.2 < 1.1", 0);
- ret |= test(, "1.1 > 2.2", 0);
+ ret = test(ctx, "1+1", 2);
+ ret |= test(ctx, "FOO+BAR", 3);
+ ret |= test(ctx, "(BAR/2)%2", 1);
+ ret |= test(ctx, "1 - -4", 5);
+ ret |= test(ctx, "(FOO-1)*2 + (BAR/2)%2 - -4", 5);
+ ret |= test(ctx, "1-1 | 1", 1);
+ ret |= test(ctx, "1-1 & 1", 0);
+ ret |= test(ctx, "min(1,2) + 1", 2);
+ ret |= test(ctx, "max(1,2) + 1", 3);
+ ret |= test(ctx, "1+1 if 3*4 else 0", 2);
+ ret |= test(ctx, "1.1 + 2.1", 3.2);
+ ret |= test(ctx, ".1 + 2.", 2.1);
+ ret |= test(ctx, "d_ratio(1, 2)", 0.5);
+ ret |= test(ctx, "d_ratio(2.5, 0)", 0);
+ ret |= test(ctx, "1.1 < 2.2", 1);
+ ret |= test(ctx, "2.2 > 1.1", 1);
+ ret |= test(ctx, "1.1 < 1.1", 0);
+ ret |= test(ctx, "2.2 > 2.2", 0);
+ ret |= test(ctx, "2.2 < 1.1", 0);
+ ret |= test(ctx, "1.1 > 2.2", 0);
- if (ret)
+ if (ret) {
+ expr__ctx_free(ctx);
return ret;
+ }
p = "FOO/0";
- ret = expr__parse(, , p, 1);
+ ret = expr__parse(, ctx, p, 1);
TEST_ASSERT_VAL("division by zero", ret == -1);
p = "BAR/";
- ret = expr__parse(, , p, 1);
+ ret = expr__parse(, ctx, p, 1);
TEST_ASSERT_VAL("missing operand", ret == -1);
- expr__ctx_clear();
+ expr__ctx_clear(ctx);
TEST_ASSERT_VAL("find other",
expr__find_other("FOO + BAR + BAZ + BOZO", "FOO",
-, 1) == 0);
- TEST_ASSERT_VAL("find other", hashmap__size() == 3);
- TEST_ASSERT_VAL("find other", hashmap__find(, "BAR",
+ctx, 1) == 0);
+ TEST_ASSERT_VAL("find other", hashmap__size(ctx->ids) == 3);
+ TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BAR",
(void **)_ptr));
- TEST_ASSERT_VAL("find other", hashmap__find(, "BAZ",
+ TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BAZ",
(void **)_ptr));
- TEST_ASSERT_VAL("find other", hashmap__find(, "BOZO",
+ TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BOZO",
(void **)_ptr));
- expr__ctx_clear();
+ expr__ctx_clear(ctx);
TEST_ASSERT_VAL("find other",
expr__find_other("EVENT1\\,param\\=?@ +
EVENT2\\,param\\=?@",
-NULL, , 3) == 0);
- TEST_ASSERT_VAL("find other", hashmap__size() == 2);
- TEST_ASSERT_VAL("find other", hashmap__find(, "EVENT1,param=3/",
+
[PATCH v5 3/5] perf metric: Rename expr__find_other.
A later change will remove the notion of other, rename the function to
expr__find_ids as this is what it populates.
Signed-off-by: Ian Rogers
---
tools/perf/tests/expr.c | 26 +-
tools/perf/tests/pmu-events.c | 9 -
tools/perf/util/expr.c| 4 ++--
tools/perf/util/expr.h| 2 +-
tools/perf/util/metricgroup.c | 2 +-
tools/perf/util/stat-shadow.c | 6 +++---
6 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
index b0a3b5fd0c00..7ccb97c73347 100644
--- a/tools/perf/tests/expr.c
+++ b/tools/perf/tests/expr.c
@@ -64,25 +64,25 @@ int test__expr(struct test *t __maybe_unused, int subtest
__maybe_unused)
TEST_ASSERT_VAL("missing operand", ret == -1);
expr__ctx_clear(ctx);
- TEST_ASSERT_VAL("find other",
- expr__find_other("FOO + BAR + BAZ + BOZO", "FOO",
-ctx, 1) == 0);
- TEST_ASSERT_VAL("find other", hashmap__size(ctx->ids) == 3);
- TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BAR",
+ TEST_ASSERT_VAL("find ids",
+ expr__find_ids("FOO + BAR + BAZ + BOZO", "FOO",
+ ctx, 1) == 0);
+ TEST_ASSERT_VAL("find ids", hashmap__size(ctx->ids) == 3);
+ TEST_ASSERT_VAL("find ids", hashmap__find(ctx->ids, "BAR",
(void **)_ptr));
- TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BAZ",
+ TEST_ASSERT_VAL("find ids", hashmap__find(ctx->ids, "BAZ",
(void **)_ptr));
- TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BOZO",
+ TEST_ASSERT_VAL("find ids", hashmap__find(ctx->ids, "BOZO",
(void **)_ptr));
expr__ctx_clear(ctx);
- TEST_ASSERT_VAL("find other",
- expr__find_other("EVENT1\\,param\\=?@ +
EVENT2\\,param\\=?@",
-NULL, ctx, 3) == 0);
- TEST_ASSERT_VAL("find other", hashmap__size(ctx->ids) == 2);
- TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "EVENT1,param=3/",
+ TEST_ASSERT_VAL("find ids",
+ expr__find_ids("EVENT1\\,param\\=?@ +
EVENT2\\,param\\=?@",
+ NULL, ctx, 3) == 0);
+ TEST_ASSERT_VAL("find ids", hashmap__size(ctx->ids) == 2);
+ TEST_ASSERT_VAL("find ids", hashmap__find(ctx->ids, "EVENT1,param=3/",
(void **)_ptr));
- TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "EVENT2,param=3/",
+ TEST_ASSERT_VAL("find ids", hashmap__find(ctx->ids, "EVENT2,param=3/",
(void **)_ptr));
expr__ctx_free(ctx);
diff --git a/tools/perf/tests/pmu-events.c b/tools/perf/tests/pmu-events.c
index 294daf568bb6..3ac70fa31379 100644
--- a/tools/perf/tests/pmu-events.c
+++ b/tools/perf/tests/pmu-events.c
@@ -502,9 +502,8 @@ static int test_parsing(void)
if (!pe->metric_expr)
continue;
expr__ctx_clear(ctx);
- if (expr__find_other(pe->metric_expr, NULL, ctx, 0)
- < 0) {
- expr_failure("Parse other failed", map, pe);
+ if (expr__find_ids(pe->metric_expr, NULL, ctx, 0) < 0) {
+ expr_failure("Parse find ids failed", map, pe);
ret++;
continue;
}
@@ -559,8 +558,8 @@ static int metric_parse_fake(const char *str)
pr_debug("parsing '%s'\n", str);
ctx = expr__ctx_new();
- if (expr__find_other(str, NULL, ctx, 0) < 0) {
- pr_err("expr__find_other failed\n");
+ if (expr__find_ids(str, NULL, ctx, 0) < 0) {
+ pr_err("expr__find_ids failed\n");
return -1;
}
diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
index e0623d38e6ee..a248d14882cc 100644
--- a/tools/perf/util/expr.c
+++ b/tools/perf/util/expr.c
@@ -287,8 +287,8 @@ int expr__parse(double *final_val, struct expr_parse_ctx
*ctx,
return __expr__parse(final_val, ctx, expr, EXPR_PARSE, runtime) ? -1 :
0;
}
-int expr__find_other(const char *expr, const char *one,
-struct expr_parse_ctx *ctx, int runtime)
+int expr__find_ids(const char *expr, const char *one,
+ struct expr_parse_ctx *ctx, int runtime)
{
int ret = __expr__parse(NULL, ctx, expr, EXPR_OTHER, runtime);
diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
index 00b941cfe6a6..955d5adb7ca4 100644
--- a/tools/perf/util/expr.h
+++ b/tools/perf/util/expr.h
@@ -43,7 +43,7 @@ int expr__resolve_id(struct
[PATCH v5 0/5] Don't compute events that won't be used in a metric.
For a metric like: EVENT1 if #smt_on else EVENT2 currently EVENT1 and EVENT2 will be measured and then when the metric is reported EVENT1 or EVENT2 will be printed depending on the value from smt_on() during the expr parsing. Computing both events is unnecessary and can lead to multiplexing as discussed in this thread: https://lore.kernel.org/lkml/20201110100346.2527031-1-irog...@google.com/ This change modifies expression parsing so that constants are considered when building the set of ids (events) and only events not contributing to a constant value are measured. v5. uses macros to reduce boiler plate in patch 5/5 as suggested by Andi Kleen . v4. reduces references to BOTTOM/NAN in patch 5/5 by using utility functions. It improves comments and fixes an unnecessary union in a peephole optimization. v3. fixes an assignment in patch 2/5. In patch 5/5 additional comments are added and useless frees are replaced by asserts. A new peephole optimization is added for the case CONST IF expr ELSE CONST, where the the constants are identical, as we don't need to evaluate the IF condition. v2. is a rebase. Ian Rogers (5): perf metric: Restructure struct expr_parse_ctx. perf metric: Use NAN for missing event IDs. perf metric: Rename expr__find_other. perf metric: Add utilities to work on ids map. perf metric: Don't compute unused events. tools/perf/tests/expr.c | 159 +++- tools/perf/tests/pmu-events.c | 42 +++-- tools/perf/util/expr.c| 136 -- tools/perf/util/expr.h| 17 +- tools/perf/util/expr.l| 9 - tools/perf/util/expr.y| 343 ++ tools/perf/util/metricgroup.c | 44 +++-- tools/perf/util/stat-shadow.c | 54 -- 8 files changed, 586 insertions(+), 218 deletions(-) -- 2.29.2.454.gaff20da3a2-goog
[PATCH v2 0/3] firmware: xilinx: Clean up series
Hi, for being able to review new changes more effectively it is good to get rid of existing kernel-doc and checkpatch violations. That's why this small clean up series. Based on https://lore.kernel.org/r/e606233d15bfdc594535dd34eb85472b42f61830.1606832997.git.michal.si...@xilinx.com Thanks, Michal Changes in v2: - keep variable name and type on the same line - reported by Joe Perches Michal Simek (3): firmware: xilinx: Remove additional newline firmware: xilinx: Add a blank line after function declaration firmware: xilinx: Properly align function parameter include/linux/firmware/xlnx-zynqmp.h | 43 1 file changed, 38 insertions(+), 5 deletions(-) -- 2.29.2
[PATCH v2 3/3] firmware: xilinx: Properly align function parameter
Fix parameters alignment reported by checkpatch --strict.
Signed-off-by: Michal Simek
---
Changes in v2:
- keep variable name and type on the same line - reported by Joe Perches
include/linux/firmware/xlnx-zynqmp.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/firmware/xlnx-zynqmp.h
b/include/linux/firmware/xlnx-zynqmp.h
index 0e7e72650ed3..edc2977b26d9 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -456,7 +456,7 @@ static inline int zynqmp_pm_sd_dll_reset(u32 node_id, u32
type)
}
static inline int zynqmp_pm_reset_assert(const enum zynqmp_pm_reset reset,
- const enum zynqmp_pm_reset_action assert_flag)
+const enum zynqmp_pm_reset_action
assert_flag)
{
return -ENODEV;
}
@@ -490,9 +490,9 @@ static inline int zynqmp_pm_release_node(const u32 node)
}
static inline int zynqmp_pm_set_requirement(const u32 node,
- const u32 capabilities,
- const u32 qos,
- const enum zynqmp_pm_request_ack ack)
+ const u32 capabilities,
+ const u32 qos,
+ const enum zynqmp_pm_request_ack
ack)
{
return -ENODEV;
}
--
2.29.2
[PATCH v2 2/3] firmware: xilinx: Add a blank line after function declaration
Fix all these issues which are also reported by checkpatch --strict.
Signed-off-by: Michal Simek
---
(no changes since v1)
include/linux/firmware/xlnx-zynqmp.h | 34
1 file changed, 34 insertions(+)
diff --git a/include/linux/firmware/xlnx-zynqmp.h
b/include/linux/firmware/xlnx-zynqmp.h
index 0db9005782d6..0e7e72650ed3 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -363,107 +363,132 @@ static inline struct zynqmp_eemi_ops
*zynqmp_pm_get_eemi_ops(void)
{
return ERR_PTR(-ENODEV);
}
+
static inline int zynqmp_pm_get_api_version(u32 *version)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_get_chipid(u32 *idcode, u32 *version)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_query_data(struct zynqmp_pm_query_data qdata,
u32 *out)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_clock_enable(u32 clock_id)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_clock_disable(u32 clock_id)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_clock_getstate(u32 clock_id, u32 *state)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_clock_setdivider(u32 clock_id, u32 divider)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_clock_getdivider(u32 clock_id, u32 *divider)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_clock_setrate(u32 clock_id, u64 rate)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_clock_getrate(u32 clock_id, u64 *rate)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_clock_setparent(u32 clock_id, u32 parent_id)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_clock_getparent(u32 clock_id, u32 *parent_id)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_set_pll_frac_mode(u32 clk_id, u32 mode)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_get_pll_frac_mode(u32 clk_id, u32 *mode)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_set_pll_frac_data(u32 clk_id, u32 data)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_get_pll_frac_data(u32 clk_id, u32 *data)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_set_sd_tapdelay(u32 node_id, u32 type, u32 value)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_sd_dll_reset(u32 node_id, u32 type)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_reset_assert(const enum zynqmp_pm_reset reset,
const enum zynqmp_pm_reset_action assert_flag)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_reset_get_status(const enum zynqmp_pm_reset reset,
u32 *status)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_init_finalize(void)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_set_suspend_mode(u32 mode)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_request_node(const u32 node, const u32
capabilities,
const u32 qos,
const enum zynqmp_pm_request_ack ack)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_release_node(const u32 node)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_set_requirement(const u32 node,
const u32 capabilities,
const u32 qos,
@@ -471,39 +496,48 @@ static inline int zynqmp_pm_set_requirement(const u32
node,
{
return -ENODEV;
}
+
static inline int zynqmp_pm_aes_engine(const u64 address, u32 *out)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_fpga_load(const u64 address, const u32 size,
const u32 flags)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_fpga_get_status(u32 *value)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_write_ggs(u32 index, u32 value)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_read_ggs(u32 index, u32 *value)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_write_pggs(u32 index, u32 value)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_read_pggs(u32 index, u32 *value)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_system_shutdown(const u32 type, const u32 subtype)
{
return -ENODEV;
}
+
static inline int zynqmp_pm_set_boot_health_status(u32 value)
{
return -ENODEV;
--
2.29.2
Re: [PATCH 3/3] firmware: xilinx: Properly align function parameter
On 01. 12. 20 20:42, Joe Perches wrote: > On Tue, 2020-12-01 at 16:50 +0100, Michal Simek wrote: >> Fix parameters alignment reported by checkpatch --strict. > > Please use a newer checkpatch as the 80 column warning > isn't enforced quite the same way. I was using it but saw 80 lines breakage in editor that's why I put it there. > >> diff --git a/include/linux/firmware/xlnx-zynqmp.h >> b/include/linux/firmware/xlnx-zynqmp.h > [] >> @@ -456,7 +456,8 @@ static inline int zynqmp_pm_sd_dll_reset(u32 node_id, >> u32 type) >> } >> >> >> static inline int zynqmp_pm_reset_assert(const enum zynqmp_pm_reset reset, >> - const enum zynqmp_pm_reset_action assert_flag) >> + const enum zynqmp_pm_reset_action >> + assert_flag) > > I think these changes aren't very good as it separates > the type from the variable name. I have retest it and I can't see any warning when they are on the same line. Will send v2 with fixing this. Thanks, Michal
[PATCH] ARM: imx_v6_v7_defconfig: enable power driver of RN5T618 PMIC family
There is a driver now for the power supply and fuel gauge functionality of that chip family, so enable them, since they are used by various i.MX6 boards, especially ebook-readers. Signed-off-by: Andreas Kemnade --- arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 221f5c340c86..70928cc48939 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -222,6 +222,7 @@ CONFIG_POWER_RESET=y CONFIG_POWER_RESET_SYSCON=y CONFIG_POWER_RESET_SYSCON_POWEROFF=y CONFIG_POWER_SUPPLY=y +CONFIG_RN5T618_POWER=m CONFIG_SENSORS_MC13783_ADC=y CONFIG_SENSORS_GPIO_FAN=y CONFIG_SENSORS_IIO_HWMON=y -- 2.20.1
Re: [RFC PATCH v1] scsi: ufs: Remove pre-defined initial VCC voltage values
On 2020-11-30 22:54, Stanley Chu wrote:
Hi Asutosh,
On Mon, 2020-11-30 at 19:07 -0800, Asutosh Das (asd) wrote:
On 11/30/2020 5:25 PM, Stanley Chu wrote:
> On Mon, 2020-11-30 at 15:54 -0800, Asutosh Das (asd) wrote:
>> On 11/30/2020 3:14 PM, Bjorn Andersson wrote:
>>> On Mon 30 Nov 16:51 CST 2020, Asutosh Das (asd) wrote:
>>>
On 11/30/2020 1:16 AM, Stanley Chu wrote:
> UFS specficication allows different VCC configurations for UFS devices,
> for example,
>(1). 2.70V - 3.60V (By default)
>(2). 1.70V - 1.95V (Activated if "vcc-supply-1p8" is declared in
> device tree)
>(3). 2.40V - 2.70V (Supported since UFS 3.x)
>
> With the introduction of UFS 3.x products, an issue is happening that
> UFS driver will use wrong "min_uV/max_uV" configuration to toggle VCC
> regulator on UFU 3.x products with VCC configuration (3) used.
>
> To solve this issue, we simply remove pre-defined initial VCC voltage
> values in UFS driver with below reasons,
>
> 1. UFS specifications do not define how to detect the VCC configuration
> supported by attached device.
>
> 2. Device tree already supports standard regulator properties.
>
> Therefore VCC voltage shall be defined correctly in device tree, and
> shall not be changed by UFS driver. What UFS driver needs to do is simply
> enabling or disabling the VCC regulator only.
>
> This is a RFC conceptional patch. Please help review this and feel
> free to feedback any ideas. Once this concept is accepted, and then
> I would post a more completed patch series to fix this issue.
>
> Signed-off-by: Stanley Chu
> ---
> drivers/scsi/ufs/ufshcd-pltfrm.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c
b/drivers/scsi/ufs/ufshcd-pltfrm.c
> index a6f76399b3ae..3965be03c136 100644
> --- a/drivers/scsi/ufs/ufshcd-pltfrm.c
> +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
> @@ -133,15 +133,7 @@ static int ufshcd_populate_vreg(struct device *dev,
const char *name,
>vreg->max_uA = 0;
>}
> - if (!strcmp(name, "vcc")) {
> - if (of_property_read_bool(np, "vcc-supply-1p8")) {
> - vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV;
> - vreg->max_uV = UFS_VREG_VCC_1P8_MAX_UV;
> - } else {
> - vreg->min_uV = UFS_VREG_VCC_MIN_UV;
> - vreg->max_uV = UFS_VREG_VCC_MAX_UV;
> - }
> - } else if (!strcmp(name, "vccq")) {
> + if (!strcmp(name, "vccq")) {
>vreg->min_uV = UFS_VREG_VCCQ_MIN_UV;
>vreg->max_uV = UFS_VREG_VCCQ_MAX_UV;
>} else if (!strcmp(name, "vccq2")) {
>
Hi Stanley
Thanks for the patch. Bao (nguyenb) was also working towards something
similar.
Would it be possible for you to take into account the scenario in which the
same platform supports both 2.x and 3.x UFS devices?
These've different voltage requirements, 2.4v-3.6v.
I'm not sure if standard dts regulator properties can support this.
>>>
>>> What is the actual voltage requirement for these devices and how does
>>> the software know what voltage to pick in this range?
>>>
>>> Regards,
>>> Bjorn
>>>
-asd
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project
>>
>> For platforms that support both 2.x (2.7v-3.6v) and 3.x (2.4v-2.7v), the
>> voltage requirements (Vcc) are 2.4v-3.6v. The software initializes the
>> ufs device at 2.95v & reads the version and if the device is 3.x, it may
>> do the following:
>> - Set the device power mode to SLEEP
>> - Disable the Vcc
>> - Enable the Vcc and set it to 2.5v
>> - Set the device power mode to ACTIVE
>>
>> All of the above may be done at HS-G1 & moved to max supported gear
>> based on the device version, perhaps?
>
> Hi Asutosh,
>
> Thanks for sharing this idea.
>
> 1. I did not see above flow defined in UFS specifications, please
> correct me if I was wrong.
>
> 2. For above flow, the concern is that I am not sure if all devices
> supporting VCC (2.4v - 2.7v) can accept higher voltage, say 2.95v, for
> version detection.
>
> 3. For version detection, another concern is that I am not sure if all
> 3.x devices support VCC (2.4v - 2.7v) only, or in other words, I am not
> sure if all 2.x devices support VCC (2.7v - 3.6v) only. The above rule
> will break any devices not obeying this "conventions".
>
> For platforms that support both 2.x (2.7v-3.6v) and 3.x (2.4v-2.7v),
>
> It would be good for UFS drivers detecting the correct voltage if the
> protocol is well-defined in specifications. Until that day, any
> "non-standard" way may be better implemented in vendor's
Re: [PATCH v4 1/3] scsi: ufs: Serialize eh_work with system PM events and async scan
Hi Can,
On Tue, 2020-12-01 at 19:47 -0800, Can Guo wrote:
> Serialize eh_work with system PM events and async scan to make sure eh_work
> does not run in parallel with them.
>
> Reviewed-by: Asutosh Das
> Reviewed-by: Hongwu Su
> Signed-off-by: Can Guo
> ---
> drivers/scsi/ufs/ufshcd.c | 64
> +--
> drivers/scsi/ufs/ufshcd.h | 1 +
> 2 files changed, 41 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 1d8134e..7e764e8 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -5597,7 +5597,9 @@ static inline void ufshcd_schedule_eh_work(struct
> ufs_hba *hba)
> static void ufshcd_err_handling_prepare(struct ufs_hba *hba)
> {
> pm_runtime_get_sync(hba->dev);
> - if (pm_runtime_suspended(hba->dev)) {
> + if (pm_runtime_status_suspended(hba->dev) || hba->is_sys_suspended) {
> + enum ufs_pm_op pm_op;
> +
> /*
>* Don't assume anything of pm_runtime_get_sync(), if
>* resume fails, irq and clocks can be OFF, and powers
> @@ -5612,7 +5614,8 @@ static void ufshcd_err_handling_prepare(struct ufs_hba
> *hba)
> if (!ufshcd_is_clkgating_allowed(hba))
> ufshcd_setup_clocks(hba, true);
> ufshcd_release(hba);
> - ufshcd_vops_resume(hba, UFS_RUNTIME_PM);
> + pm_op = hba->is_sys_suspended ? UFS_RUNTIME_PM : UFS_SYSTEM_PM;
Perhaps typo here? Shall be as below?
pm_op = hba->is_sys_suspended ? UFS_SYSTEM_PM : UFS_RUNTIME_PM;
Otherwise looks good to me.
Thanks,
Stanley Chu
> + ufshcd_vops_resume(hba, pm_op);
> } else {
> ufshcd_hold(hba, false);
> if (hba->clk_scaling.is_allowed) {
> @@ -5633,7 +5636,7 @@ static void ufshcd_err_handling_unprepare(struct
> ufs_hba *hba)
>
> static inline bool ufshcd_err_handling_should_stop(struct ufs_hba *hba)
> {
> - return (hba->ufshcd_state == UFSHCD_STATE_ERROR ||
> + return (!hba->is_powered || hba->ufshcd_state == UFSHCD_STATE_ERROR ||
> (!(hba->saved_err || hba->saved_uic_err || hba->force_reset ||
> ufshcd_is_link_broken(hba;
> }
> @@ -5646,6 +5649,7 @@ static void ufshcd_recover_pm_error(struct ufs_hba *hba)
> struct request_queue *q;
> int ret;
>
> + hba->is_sys_suspended = false;
> /*
>* Set RPM status of hba device to RPM_ACTIVE,
>* this also clears its runtime error.
> @@ -5704,11 +5708,13 @@ static void ufshcd_err_handler(struct work_struct
> *work)
>
> hba = container_of(work, struct ufs_hba, eh_work);
>
> + down(>eh_sem);
> spin_lock_irqsave(hba->host->host_lock, flags);
> if (ufshcd_err_handling_should_stop(hba)) {
> if (hba->ufshcd_state != UFSHCD_STATE_ERROR)
> hba->ufshcd_state = UFSHCD_STATE_OPERATIONAL;
> spin_unlock_irqrestore(hba->host->host_lock, flags);
> + up(>eh_sem);
> return;
> }
> ufshcd_set_eh_in_progress(hba);
> @@ -5716,20 +5722,18 @@ static void ufshcd_err_handler(struct work_struct
> *work)
> ufshcd_err_handling_prepare(hba);
> spin_lock_irqsave(hba->host->host_lock, flags);
> ufshcd_scsi_block_requests(hba);
> - /*
> - * A full reset and restore might have happened after preparation
> - * is finished, double check whether we should stop.
> - */
> - if (ufshcd_err_handling_should_stop(hba)) {
> - if (hba->ufshcd_state != UFSHCD_STATE_ERROR)
> - hba->ufshcd_state = UFSHCD_STATE_OPERATIONAL;
> - goto out;
> - }
> hba->ufshcd_state = UFSHCD_STATE_RESET;
>
> /* Complete requests that have door-bell cleared by h/w */
> ufshcd_complete_requests(hba);
>
> + /*
> + * A full reset and restore might have happened after preparation
> + * is finished, double check whether we should stop.
> + */
> + if (ufshcd_err_handling_should_stop(hba))
> + goto skip_err_handling;
> +
> if (hba->dev_quirks & UFS_DEVICE_QUIRK_RECOVERY_FROM_DL_NAC_ERRORS) {
> bool ret;
>
> @@ -5737,17 +5741,10 @@ static void ufshcd_err_handler(struct work_struct
> *work)
> /* release the lock as ufshcd_quirk_dl_nac_errors() may sleep */
> ret = ufshcd_quirk_dl_nac_errors(hba);
> spin_lock_irqsave(hba->host->host_lock, flags);
> - if (!ret && !hba->force_reset && ufshcd_is_link_active(hba))
> + if (!ret && ufshcd_err_handling_should_stop(hba))
> goto skip_err_handling;
> }
>
> - if (hba->force_reset || ufshcd_is_link_broken(hba) ||
> - ufshcd_is_saved_err_fatal(hba) ||
> - ((hba->saved_err & UIC_ERROR) &&
> - (hba->saved_uic_err & (UFSHCD_UIC_DL_NAC_RECEIVED_ERROR |
> -
Re: [PATCH -next v2] firmware: xilinx: Mark pm_api_features_map with static keyword
On 01. 12. 20 22:26, Greg KH wrote: > On Tue, Dec 01, 2020 at 01:03:59PM +0100, Michal Simek wrote: >> >> >> On 01. 12. 20 12:51, Zou Wei wrote: >>> Fix the following sparse warning: >>> >>> drivers/firmware/xilinx/zynqmp.c:32:1: warning: symbol >>> 'pm_api_features_map' was not declared. Should it be static? >>> >>> Signed-off-by: Zou Wei >>> --- >>> drivers/firmware/xilinx/zynqmp.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/firmware/xilinx/zynqmp.c >>> b/drivers/firmware/xilinx/zynqmp.c >>> index d08ac82..fd95ede 100644 >>> --- a/drivers/firmware/xilinx/zynqmp.c >>> +++ b/drivers/firmware/xilinx/zynqmp.c >>> @@ -29,7 +29,7 @@ >>> #define PM_API_FEATURE_CHECK_MAX_ORDER 7 >>> >>> static bool feature_check_enabled; >>> -DEFINE_HASHTABLE(pm_api_features_map, PM_API_FEATURE_CHECK_MAX_ORDER); >>> +static DEFINE_HASHTABLE(pm_api_features_map, >>> PM_API_FEATURE_CHECK_MAX_ORDER); >>> >>> /** >>> * struct pm_api_feature_data - PM API Feature data >>> >> >> The patch is good but I am missing fixed tag to get it to LTS. > > Why is this needed for any stable kernel release? It's a sparse > warning, no one trips across those in stable kernels... Ok thanks for explanation. Applied to zynqmp/soc branch. Thanks, Michal
Re: [PATCH] x86/PCI: Convert force_disable_hpet() to standard quirk
On Mon, 2020-11-30 at 20:21 +0100, Thomas Gleixner wrote:
> Feng,
>
> On Fri, Nov 27 2020 at 14:11, Feng Tang wrote:
> > On Fri, Nov 27, 2020 at 12:27:34AM +0100, Thomas Gleixner wrote:
> > > On Thu, Nov 26 2020 at 09:24, Feng Tang wrote:
> > > Yes, that can happen. But OTOH, we should start to think about
> > > the
> > > requirements for using the TSC watchdog.
My original proposal is to disable jiffies and refined-jiffies as the
clocksource watchdog, because they are not reliable and it's better to
use clocksource that has a hardware counter as watchdog, like the patch
below, which I didn't sent out for upstream.
>From cf9ce0ecab8851a3745edcad92e072022af3dbd9 Mon Sep 17 00:00:00 2001
From: Zhang Rui
Date: Fri, 19 Jun 2020 22:03:23 +0800
Subject: [RFC PATCH] time/clocksource: do not use refined-jiffies as watchdog
On IA platforms, if HPET is disabled, either via x86 early-quirks, or
via kernel commandline, refined-jiffies will be used as clocksource
watchdog in early boot phase, before acpi_pm timer registered.
This is not a problem if jiffies are accurate.
But in some cases, for example, when serial console is enabled, it may
take several milliseconds to write to the console, with irq disabled,
frequently. Thus many ticks may become longer than it should be.
Using refined-jiffies as watchdog in this case breaks the system because
a) duration calculated by refined-jiffies watchdog is always consistent
with the watchdog timeout issued using add_timer(), say, around 500ms.
b) duration calculated by the running clocksource, usually TSC on IA
platforms, reflects the real time cost, which may be much larger.
This results in the running clocksource being disabled erroneously.
This is reproduced on ICL because HPET is disabled in x86 early-quirks,
and also reproduced on a KBL and a WHL platform when HPET is disabled
via command line.
BTW, commit fd329f276eca
("x86/mtrr: Skip cache flushes on CPUs with cache self-snooping") is
another example that refined-jiffies causes the same problem when ticks
become slow for some other reason.
IMO, the right solution is to only use hardware clocksource as watchdog.
Then even if ticks are slow, both the running clocksource and the watchdog
returns real time cost, and they still match.
Signed-off-by: Zhang Rui
---
kernel/time/clocksource.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 02441ead3c3b..e7e703858fa6 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -364,6 +364,10 @@ static void clocksource_select_watchdog(bool fallback)
watchdog = NULL;
list_for_each_entry(cs, _list, list) {
+ /* Do not use refined-jiffies as clocksource watchdog */
+ if (cs->rating <= 2)
+ continue;
+
/* cs is a clocksource to be watched. */
if (cs->flags & CLOCK_SOURCE_MUST_VERIFY)
continue;
--
2.17.1
> > >
> > > I'm inclined to lift that requirement when the CPU has:
> > >
> > > 1) X86_FEATURE_CONSTANT_TSC
> > > 2) X86_FEATURE_NONSTOP_TSC
> > > 3) X86_FEATURE_NONSTOP_TSC_S3
> >
> > IIUC, this feature exists for several generations of Atom
> > platforms,
> > and it is always coupled with 1) and 2), so it could be skipped for
> > the checking.
>
> Yes, we can ignore that bit as it's not widely available and not
> required to solve the problem.
>
> > > 4) X86_FEATURE_TSC_ADJUST
> > >
> > > 5) At max. 4 sockets
> > >
Should we consider some other corner cases like TSC is not used as
clocksource? refined_jiffies watchdog can break any other hardware
clocksource when it becomes inaccurate.
> > > The only reason I hate to disable HPET upfront at least during
> > > boot is
> > > that HPET is the best mechanism for the refined TSC calibration.
> > > PMTIMER
> > > sucks because it's slow and wraps around pretty quick.
> > >
> > > So we could do the following even on platforms where HPET stops
> > > in some
> > > magic PC? state:
> > >
> > > - Register it during early boot as clocksource
> > >
> > > - Prevent the enablement as clockevent and the chardev hpet
> > > timer muck
> > >
> > > - Prevent the magic PC? state up to the point where the refined
> > > TSC calibration is finished.
> > >
> > > - Unregister it once the TSC has taken over as system
> > > clocksource and
> > > enable the magic PC? state in which HPET gets disfunctional.
> >
On the other side, for ICL, the HPET problem is observed on early
samples, and I didn't reproduce the problem on new ones I have.
But I need to confirm internally if it is safe to re-enable it first.
thanks,
rui
> > This looks reasonable to me.
> >
> > I have thought about lowering the hpet rating to lower than
> > PMTIMER, so it
> > still contributes in early boot phase, and fades out after PMTIMER
> > is
> > initialised.
>
> Not a good idea. pm_timer is initialized
[PATCH v2] tty/serial/imx: Enable TXEN bit in imx_poll_init().
From: Mingrui Ren As described in Documentation, poll_init() is called by kgdb to initialize hardware which supports both poll_put_char() and poll_get_char(). It's necessary to enable TXEN bit, otherwise, it will cause hardware fault and kernel panic when calling imx_poll_put_char(). Generally, if use /dev/ttymxc0 as kgdb console as well as system console, ttymxc0 is initialized early by system console which does enable TXEN bit.But when use /dev/ttymxc1 as kgbd console, ttymxc1 is only initialized by imx_poll_init() cannot enable the TXEN bit, which will cause kernel panic. Signed-off-by: Mingrui Ren --- Changes in v2: - Add ' ' around '|' for better code style. - Re-create patch on the latest master branch. drivers/tty/serial/imx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index cacf7266a262..a66301b3b33d 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -1881,7 +1881,7 @@ static int imx_uart_poll_init(struct uart_port *port) ucr1 |= UCR1_UARTEN; ucr1 &= ~(UCR1_TRDYEN | UCR1_RTSDEN | UCR1_RRDYEN); - ucr2 |= UCR2_RXEN; + ucr2 |= UCR2_RXEN | UCR2_TXEN; ucr2 &= ~UCR2_ATEN; imx_uart_writel(sport, ucr1, UCR1); -- 2.28.0
Re: [PATCH] phy/rockchip: Make PHY_ROCKCHIP_INNO_HDMI depend on HAS_IOMEM to fix build error
On 24-11-20, 19:11, Tiezhu Yang wrote: > devm_ioremap_resource() will be not built in lib/devres.c if > CONFIG_HAS_IOMEM is not set, and then there exists a build > error about undefined reference to "devm_ioremap_resource" > in the file phy-rockchip-inno-hdmi.c under COMPILE_TEST and > CONFIG_PHY_ROCKCHIP_INNO_HDMI, make PHY_ROCKCHIP_INNO_HDMI > depend on HAS_IOMEM to fix it. Applied, thanks -- ~Vinod
Re: linux-next: build failure after merge of the block tree
On Wed, Dec 02, 2020 at 03:01:49PM +1100, Stephen Rothwell wrote: > I applied the following merge fix patch (which may, or may not, be > correct but fixes the build). The fixes are exactly what I would have done. Thanks!
Re: [PATCH] soundwire: master: use pm_runtime_set_active() on add
On 24-11-20, 21:07, Bard Liao wrote: > From: Pierre-Louis Bossart > > The 'master' device acts as a glue layer used during bus > initialization only, and it needs to be 'transparent' for pm_runtime > management. Its behavior should be that it becomes active when one of > its children becomes active, and suspends when all of its children are > suspended. > > In our tests on Intel platforms, we routinely see these sort of > warnings on the initial boot: > > [ 21.447345] rt715 sdw:3:25d:715:0: runtime PM trying to activate > child device sdw:3:25d:715:0 but parent (sdw-master-3) is not active > > This is root-caused to a missing setup to make the device 'active' on > probe. Since we don't want the device to remain active forever after > the probe, the autosuspend configuration is also enabled at the end of > the probe - the device will actually autosuspend only in the case > where there are no devices physically attached. In practice, the > master device will suspend when all its children are no longer active. Applied, thanks -- ~Vinod
Re: [PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM
Hi Adrian, On Tue, Dec 01, 2020 at 08:55:37PM +0100, John Paul Adrian Glaubitz wrote: > Hi Mike! > > On 12/1/20 4:07 PM, John Paul Adrian Glaubitz wrote: > > This fixes the issue for me. > > > > Tested-by: John Paul Adrian Glaubitz > > I just booted the kernel from the linux-mm branch and I can't get the hpsa > driver > to work anymore. Even if I compile it into the kernel, the driver is no longer > loaded and hence I can't access the disks. > > Any idea what could be wrong? I know nearly nothing about SCSI, I can only suggest to enable all the debug options available and see if anything shows up :) > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > -- Sincerely yours, Mike.
Re: [RFC PATCH v2 0/6] fsdax: introduce fs query to support reflink
Hi Dave,
On 2020/11/30 上午6:47, Dave Chinner wrote:
On Mon, Nov 23, 2020 at 08:41:10AM +0800, Shiyang Ruan wrote:
The call trace is like this:
memory_failure()
pgmap->ops->memory_failure() => pmem_pgmap_memory_failure()
gendisk->fops->block_lost() => pmem_block_lost() or
md_blk_block_lost()
sb->s_ops->storage_lost()=> xfs_fs_storage_lost()
xfs_rmap_query_range()
xfs_storage_lost_helper()
mf_recover_controller->recover_fn => \
memory_failure_dev_pagemap_kill_procs()
The collect_procs() and kill_procs() are moved into a callback which
is passed from memory_failure() to xfs_storage_lost_helper(). So we
can call it when a file assocaited is found, instead of creating a
file list and iterate it.
The fsdax & reflink support for XFS is not contained in this patchset.
This looks promising - the overall architecture is a lot more
generic and less dependent on knowing about memory, dax or memory
failures. A few comments that I think would further improve
understanding the patchset and the implementation:
Thanks for your kindly comment. It gives me confidence.
- the order of the patches is inverted. It should start with a
single patch introducing the mf_recover_controller structure for
callbacks, then introduce pgmap->ops->memory_failure, then
->block_lost, then the pmem and md implementations of ->block
list, then ->storage_lost and the XFS implementations of
->storage_lost.
Yes, it will be easier to understand the patchset in this order.
But I have something unsure: for example, I introduce ->memory_failure()
firstly, but the implementation of ->memory_failure() needs to call
->block_lost() which is supposed to be introduced in the next patch. So,
I am not sure the code is supposed to be what in the implementation of
->memory_failure() in pmem? To avoid this situation, I committed the
patches in the inverted order: lowest level first, then its caller, and
then caller's caller.
I am trying to sort out the order. How about this:
Patch i.
Introduce ->memory_failure()
- just introduce interface, without implementation
Patch i++.
Introduce ->block_lost()
- introduce interface and implement ->memory_failure()
in pmem, so that it can call ->block_lost()
Patch i++.
(similar with above, skip...)
- I think the names "block_lost" and "storage_lost" are misleading.
It's more like a "media failure" or a general "data corruption"
event at a specific physical location. The data may not be "lost"
but only damaged, so we might be able to recover from it without
"losing" anything. Hence I think they could be better named,
perhaps just "->corrupt_range"
'corrupt' sounds better. (I'm not good at naming functions...)
- need to pass a {offset,len} pair through the chain, not just a
single offset. This will allow other types of devices to report
different ranges of failures, from a single sector to an entire
device.
Yes, it's better to add the length. I restrictively thought that
memory-failure on pmem should affect one single page at one time.
- I'm not sure that passing the mf_recover_controller structure
through the corruption event chain is the right thing to do here.
A block device could generate this storage failure callback if it
detects an unrecoverable error (e.g. during a MD media scrub or
rebuild/resilver failure) and in that case we don't have PFNs or
memory device failure functions to perform.
IOWs, I think the action that is taken needs to be independent of
the source that generated the error. Even for a pmem device, we
can be using the page cache, so it may be possible to recover the
pmem error by writing the cached page (if it exists) back over the
pmem.
Hence I think that the recover function probably needs to be moved
to the address space ops, because what we do to recover from the
error is going to be dependent on type of mapping the filesystem
is using. If it's a DAX mapping, we call back into a generic DAX
function that does the vma walk and process kill functions. If it
is a page cache mapping, then if the page is cached then we can
try to re-write it to disk to fix the bad data, otherwise we treat
it like a writeback error and report it on the next
write/fsync/close operation done on that file.
This gets rid of the mf_recover_controller altogether and allows
the interface to be used by any sort of block device for any sort
of bottom-up reporting of media/device failures.
Moving the recover function to the address_space ops looks a better
idea. But I think that the error handler for page cache mapping is
finished well in memory-failure. The memory-failure is also reused to
handles anonymous page. If we move the recover function to
address_space ops, I think we also need to refactor the existing handler
for
Re: [PATCH v2 0/5] regmap/SoundWire/ASoC: Add SoundWire SDCA support
Hi Mark,
On 01-12-20, 14:53, Mark Brown wrote:
> On Tue, Dec 01, 2020 at 08:35:42AM -0600, Pierre-Louis Bossart wrote:
> > On 11/30/20 10:11 PM, Vinod Koul wrote:
>
> > > I see Mark has already applied 1-3 ..
>
> > Sorry, I thought Mark had reversed the entire series.
>
> Yeah, I just backed out the one change for the driver.
>
> > Vinod, would you mind providing a tag for Mark then? The following commit is
> > needed to compile:
>
> > b7cab9be7c161 ('soundwire: SDCA: detect sdca_cascade interrupt')
>
> That'd work, looks like there's only one fix patch it's based off.
I have created the tag, please pull:
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire.git
tags/soundwire-for-asoc-5.11
for you to fetch changes up to b7cab9be7c16128a0de21ed7ae67211838813437:
soundwire: SDCA: detect sdca_cascade interrupt (2020-11-24 14:09:31 +0530)
soundwire-for-asoc-5.11
Tag for asoc to resolve build dependency with commit b7cab9be7c16
("soundwire: SDCA: detect sdca_cascade interrupt")
Pierre-Louis Bossart (1):
soundwire: SDCA: detect sdca_cascade interrupt
Srinivas Kandagatla (1):
soundwire: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute
drivers/soundwire/bus.c | 28 +++-
drivers/soundwire/sysfs_slave_dpn.c | 1 +
include/linux/soundwire/sdw.h | 4
3 files changed, 32 insertions(+), 1 deletion(-)
--
~Vinod
signature.asc
Description: PGP signature
Re: [RFC PATCH 11/13] fs/userfaultfd: complete write asynchronously
> On Nov 28, 2020, at 4:45 PM, Nadav Amit wrote: > > From: Nadav Amit > > Userfaultfd writes can now be used for copy/zeroing. When using iouring > with userfaultfd, performing the copying/zeroing on the faulting thread > instead of the handler/iouring thread has several advantages: > > (1) The data of the faulting thread will be available on the local > caches, which would make subsequent memory accesses faster. > > (2) find_vma() would be able to use the vma-cache, which cannot be done > from a different process or io-uring kernel thread. > > (3) The page is more likely to be allocated on the correct NUMA node. > > To do so, userfaultfd work queue structs are extended to hold the > information that is required for the faulting thread to copy/zero. The > handler wakes one of the faulting threads to perform the copy/zero and > that thread wakes the other threads after the zero/copy is done. I noticed some bugs of mine in this patch, but more importantly I realized that the there may be a more performant solution to do the copying on the faulting thread - without async-writes. Please do not review this patch and the next one (12/13). Feedback for the rest of the series is of course welcomed. Regards, Nadav
[PATCH] optee: extend normal memory check to also write-through
ARMv7 Architecture Reference Manual [1] section A3.5.5 details Normal
memory type, together with cacheability attributes that could be applied
to memory regions defined as "Normal memory".
Section B2.1.2 of the Architecture Reference Manual [1] also provides
details regarding the Memory attributes that could be assigned to
particular memory regions, which includes the descrption of cacheability
attributes and cache allocation hints.
Memory type and cacheability attributes forms 2 separate definitions,
where cacheability attributes defines a mechanism of coherency control
rather than the type of memory itself.
In other words: Normal memory type can be configured with several
combination of cacheability attributes, namely:
- Write-Through (WT)
- Write-Back (WB) followed by cache allocation hint:
- Write-Allocate
- No Write-Allocate (also known as Read-Allocate)
Those types are mapped in the kernel to corresponding macros:
- Write-Through: L_PTE_MT_WRITETHROUGH
- Write-Back Write-Allocate: L_PTE_MT_WRITEALLOC
- Write-Back Read-Allocate: L_PTE_MT_WRITEBACK
Current implementation of the op-tee driver takes in account only 2 last
memory region types, while performing a check if the memory block is
allocated as "Normal memory", leaving Write-Through allocations to be
not considered.
Extend verification mechanism to include also Normal memory regios,
which are designated with Write-Through cacheability attributes.
Link: [1]: https://developer.arm.com/documentation/ddi0406/cd
Fixes: 853735e40424 ("optee: add writeback to valid memory type")
Cc: sta...@vger.kernel.org
Signed-off-by: Andrey Zhizhikin
---
drivers/tee/optee/call.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
index c981757ba0d4..8da27d02a2d6 100644
--- a/drivers/tee/optee/call.c
+++ b/drivers/tee/optee/call.c
@@ -535,7 +535,8 @@ static bool is_normal_memory(pgprot_t p)
{
#if defined(CONFIG_ARM)
return (((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEALLOC) ||
- ((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEBACK));
+ ((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEBACK) ||
+ ((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITETHROUGH));
#elif defined(CONFIG_ARM64)
return (pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL);
#else
--
2.17.1
Re: [PATCH v2] phy: samsung: Merge Kconfig for Exynos5420 and Exynos5250
On 02-12-20, 07:47, Marek Szyprowski wrote: > Exynos5420 variant of USB2 PHY is handled by the same code as the > Exynos5250 one. Introducing a separate Kconfig symbol for it was an > over-engineering, which turned out to cause build break for certain > configurations: > > ERROR: modpost: "exynos5420_usb2_phy_config" > [drivers/phy/samsung/phy-exynos-usb2.ko] undefined! > > Fix this by removing PHY_EXYNOS5420_USB2 symbol and using > PHY_EXYNOS5250_USB2 also for Exynos5420 SoCs. Applied, thanks -- ~Vinod
[PATCH v6 4/4] mmc: sdhci-of-arasan: Enable UHS-1 support for Keem Bay SOC
From: Muhammad Husaini Zulkifli
Keem Bay SOC can support dual voltage operations for GPIO SD Pins to
either 1.8V or 3.3V for bus IO line power. In order to operate the GPIOs
line for Clk,Cmd and Data on Keem Bay Hardware, it is important to
configure the supplied voltage applied to their I/O Rail and the output
of the i2c expander pin. Final Voltage applied on the GPIOs Line are
dependent by both supplied voltage rail and expander pin output as it is
been set after passing through the voltage sense resistor.
The Keem Bay HW is somewhat unique in the way of how IO bus line voltage
are been controlled. Output of the Expander pins is been configured using
regulator. Voltage rail output is being configured using
keembay_io_rail_supplied_voltage() API in the sdhci driver directly.
Pin control based implementation becomes problematic to control the
voltage rail due to the base address of Always On Register is
different from the base address of GPIO(Pinctrl). Thus, there is
no way to control the I/O Rail using GPIO Pad configuration.
On the other hand, using ARM SMC (Secure Monitor Call) directly from
pin control driver for the sake of implement it as pin control model
is not a good approach.
This patch was tested with Keem Bay EVM.
Signed-off-by: Muhammad Husaini Zulkifli
Reviewed-by: Andy Shevchenko
Reviewed-by: Adrian Hunter
Acked-by: Michal Simek
---
drivers/mmc/host/sdhci-of-arasan.c | 244 +
1 file changed, 244 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index 196e3d65277e..00ecdf54128c 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "cqhci.h"
#include "sdhci-pltfm.h"
@@ -79,6 +80,8 @@ struct sdhci_arasan_soc_ctl_field {
* @baseclkfreq: Where to find corecfg_baseclkfreq
* @clockmultiplier: Where to find corecfg_clockmultiplier
* @support64b:Where to find SUPPORT64B bit
+ * @otap_delay:Where to find otap_delay
+ * @sel_clk_buffer:Where to find clock buffer delay
* @hiword_update: If true, use HIWORD_UPDATE to access the syscon
*
* It's up to the licensee of the Arsan IP block to make these available
@@ -89,6 +92,8 @@ struct sdhci_arasan_soc_ctl_map {
struct sdhci_arasan_soc_ctl_field baseclkfreq;
struct sdhci_arasan_soc_ctl_field clockmultiplier;
struct sdhci_arasan_soc_ctl_field support64b;
+ struct sdhci_arasan_soc_ctl_field otap_delay;
+ struct sdhci_arasan_soc_ctl_field sel_clk_buffer;
boolhiword_update;
};
@@ -189,6 +194,8 @@ static const struct sdhci_arasan_soc_ctl_map
intel_keembay_soc_ctl_map = {
.baseclkfreq = { .reg = 0x0, .width = 8, .shift = 14 },
.clockmultiplier = { .reg = 0x4, .width = 8, .shift = 14 },
.support64b = { .reg = 0x4, .width = 1, .shift = 24 },
+ .otap_delay = { .reg = 0x24, .width = 5, .shift = 23 },
+ .sel_clk_buffer = { .reg = 0x2c, .width = 3, .shift = 25 },
.hiword_update = false,
};
@@ -364,6 +371,144 @@ static int sdhci_arasan_voltage_switch(struct mmc_host
*mmc,
return -EINVAL;
}
+/**
+ * sdhci_arasan_keembay_io_line_supply_operation - Supply for the bus IO line
power
+ *
+ * @mmc: Pointer to sdhci_host
+ * @ios: Pointer to IO bus setting
+ *
+ * For Keem Bay HW, in order to operate the GPIOs line for Clk,Cmd and Data,
+ * it is important to configure the supplied voltage applied to their I/O Rail
+ * and the output of the i2c expander Pin.
+ *
+ * Note that to configure the voltage rail setting, specific bits in AON_CFG
+ * register must be set. While to configure the i2c expander pin output,
+ * gpio regulator modelling is been used to control the pin state.
+ *
+ * Always on Domain register having different base address from GPIO base
address
+ * and it is a secure register. There is no way to control the I/O Voltage Rail
+ * from the GPIO Pad. SMC CALL is been used to set the bits in AON_CFG1
register.
+ *
+ * Final Voltage applied on the GPIOs Line are dependent by both supplied
voltage
+ * I/O Rail and expander pin output as it is been set after passing through the
+ * voltage sense resistor.
+ *
+ * Return: 0 on success and error value on error
+ */
+static int sdhci_arasan_keembay_io_line_supply_operation(struct mmc_host *mmc,
+ struct mmc_ios *ios)
+{
+ int ret, min_uV, max_uV, volt_rail;
+
+ if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_180) {
+ min_uV = IOV_1V8;
+ max_uV = IOV_1V8;
+ volt_rail = KEEMBAY_SET_1V8_IO_RAIL;
+ } else {
+ min_uV = IOV_3V3;
+ max_uV = IOV_3V3;
+ volt_rail = KEEMBAY_SET_3V3_IO_RAIL;
+ }
+
+ /* If no vqmmc supply then we can't
Re: [PATCH net-next] octeontx2-af: debugfs: delete dead code
On Wed, Dec 2, 2020 at 12:28 PM Dan Carpenter wrote: > > These debugfs never return NULL so all this code will never be run. > > In the normal case, (and in this case particularly), the debugfs > functions are not supposed to be checked for errors so all this error > checking code can be safely deleted. > > Signed-off-by: Dan Carpenter > --- Thanks for the changes.
Re: [PATCH v2 2/3] ARM: dts: aspeed: Add AST2600 edac into common devicetree
On Wed, 2 Dec 2020 at 06:37, Troy Lee wrote:
>
> Adding Aspeed AST2600 edac node into common devicetree.
>
> Signed-off-by: Troy Lee
Reviewed-by: Joel Stanley
> ---
> arch/arm/boot/dts/aspeed-g6.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi
> b/arch/arm/boot/dts/aspeed-g6.dtsi
> index 97ca743363d7..fb144515f397 100644
> --- a/arch/arm/boot/dts/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g6.dtsi
> @@ -69,6 +69,12 @@
> always-on;
> };
>
> + edac: sdram@1e6e {
> + compatible = "aspeed,ast2600-sdram-edac", "syscon";
> + reg = <0x1e6e 0x174>;
> + interrupts = ;
> + };
> +
> ahb {
> compatible = "simple-bus";
> #address-cells = <1>;
> --
> 2.17.1
>
[PATCH v6 3/4] dt-bindings: mmc: Add phys, vmmc and vqmmc supplies for Keem Bay SOC
From: Muhammad Husaini Zulkifli Add DT bindings of vmmc and vqmmc supplies of regulator and phys for the phandle of sd0_phy which contain additional property for otap delay and sel_clk_buffer. Signed-off-by: Muhammad Husaini Zulkifli --- Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml index 0753289fba84..0cbfdd840889 100644 --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml @@ -83,7 +83,7 @@ properties: - const: intel,keembay-sdhci-5.1-sd # Intel Keem Bay SD controller description: For this device it is strongly suggested to include - arasan,soc-ctl-syscon. + arasan,soc-ctl-syscon, phys, vmmc-supply and vqmmc-supply. - const: intel,keembay-sdhci-5.1-sdio # Intel Keem Bay SDIO controller description: For this device it is strongly suggested to include @@ -299,5 +299,9 @@ examples: clock-names = "clk_xin", "clk_ahb"; clocks = <_clk KEEM_BAY_PSS_AUX_SD0>, <_clk KEEM_BAY_PSS_SD0>; + phys = <_phy>; + phy-names = "phy_arasan"; arasan,soc-ctl-syscon = <_phy_syscon>; + vmmc-supply = <_sd0_vcc>; + vqmmc-supply = <_sd0_vqcc>; }; -- 2.17.1
[PATCH v6 2/4] firmware: keembay: Add support for Trusted Firmware Service call
From: Muhammad Husaini Zulkifli
Export inline function to encapsulate AON_CFG1 for controling the
I/O Rail supplied voltage levels which communicate with Trusted Firmware.
Signed-off-by: Muhammad Husaini Zulkifli
Acked-by: Michal Simek
Acked-by: Sudeep Holla
---
include/linux/firmware/intel/keembay.h | 54 ++
1 file changed, 54 insertions(+)
create mode 100644 include/linux/firmware/intel/keembay.h
diff --git a/include/linux/firmware/intel/keembay.h
b/include/linux/firmware/intel/keembay.h
new file mode 100644
index ..b5e3e490807e
--- /dev/null
+++ b/include/linux/firmware/intel/keembay.h
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Intel Keembay SOC Firmware API Layer
+ *
+ * Copyright (C) 2020, Intel Corporation
+ *
+ * Author: Muhammad Husaini Zulkifli
+ */
+
+#ifndef __FIRMWARE_KEEMBAY_SMC_H__
+#define __FIRMWARE_KEEMBAY_SMC_H__
+
+#include
+
+/*
+ * This file defines an API function that can be called by a device driver in
order to
+ * communicate with Trusted Firmware - A profile(TF-A) or Trusted Firmware - M
profile (TF-M).
+ */
+
+#define KEEMBAY_SET_1V8_IO_RAIL1
+#define KEEMBAY_SET_3V3_IO_RAIL0
+
+#define IOV_1V8180
+#define IOV_3V3330
+
+#define ARM_SMCCC_SIP_KEEMBAY_SET_SD_VOLTAGE \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32,\
+ ARM_SMCCC_OWNER_SIP, \
+ 0xFF26)
+
+#if IS_ENABLED(CONFIG_HAVE_ARM_SMCCC_DISCOVERY)
+/*
+ * Voltage applied on the IO Rail is controlled from the Always On Register
using specific
+ * bits in AON_CGF1 register. This is a secure register. Keem Bay SOC cannot
exposed this
+ * register address to the outside world.
+ */
+static inline int keembay_io_rail_supplied_voltage(int volt)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_SIP_KEEMBAY_SET_SD_VOLTAGE, volt, );
+ if ((int)res.a0 < 0)
+ return -EINVAL;
+
+ return 0;
+}
+#else
+static inline int keembay_io_rail_supplied_voltage(int volt)
+{
+ return -ENODEV;
+}
+#endif
+#endif /* __FIRMWARE_KEEMBAY_SMC_H__ */
--
2.17.1
[PATCH v6 1/4] mmc: sdhci-of-arasan: Add structure device pointer in probe func
From: Muhammad Husaini Zulkifli
Add struct device *dev in probe func() so that it can widely use in
probe to make code more readable.
Signed-off-by: Muhammad Husaini Zulkifli
Reviewed-by: mark gross
---
drivers/mmc/host/sdhci-of-arasan.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index d25a4b50c2f3..196e3d65277e 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -1508,9 +1508,10 @@ static int sdhci_arasan_probe(struct platform_device
*pdev)
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_arasan_data *sdhci_arasan;
struct device_node *np = pdev->dev.of_node;
+ struct device *dev = >dev;
const struct sdhci_arasan_of_data *data;
- match = of_match_node(sdhci_arasan_of_match, pdev->dev.of_node);
+ match = of_match_node(sdhci_arasan_of_match, dev->of_node);
data = match->data;
host = sdhci_pltfm_init(pdev, data->pdata, sizeof(*sdhci_arasan));
@@ -1524,42 +1525,42 @@ static int sdhci_arasan_probe(struct platform_device
*pdev)
sdhci_arasan->soc_ctl_map = data->soc_ctl_map;
sdhci_arasan->clk_ops = data->clk_ops;
- node = of_parse_phandle(pdev->dev.of_node, "arasan,soc-ctl-syscon", 0);
+ node = of_parse_phandle(dev->of_node, "arasan,soc-ctl-syscon", 0);
if (node) {
sdhci_arasan->soc_ctl_base = syscon_node_to_regmap(node);
of_node_put(node);
if (IS_ERR(sdhci_arasan->soc_ctl_base)) {
- ret = dev_err_probe(>dev,
+ ret = dev_err_probe(dev,
PTR_ERR(sdhci_arasan->soc_ctl_base),
"Can't get syscon\n");
goto err_pltfm_free;
}
}
- sdhci_arasan->clk_ahb = devm_clk_get(>dev, "clk_ahb");
+ sdhci_arasan->clk_ahb = devm_clk_get(dev, "clk_ahb");
if (IS_ERR(sdhci_arasan->clk_ahb)) {
- dev_err(>dev, "clk_ahb clock not found.\n");
+ dev_err(dev, "clk_ahb clock not found.\n");
ret = PTR_ERR(sdhci_arasan->clk_ahb);
goto err_pltfm_free;
}
- clk_xin = devm_clk_get(>dev, "clk_xin");
+ clk_xin = devm_clk_get(dev, "clk_xin");
if (IS_ERR(clk_xin)) {
- dev_err(>dev, "clk_xin clock not found.\n");
+ dev_err(dev, "clk_xin clock not found.\n");
ret = PTR_ERR(clk_xin);
goto err_pltfm_free;
}
ret = clk_prepare_enable(sdhci_arasan->clk_ahb);
if (ret) {
- dev_err(>dev, "Unable to enable AHB clock.\n");
+ dev_err(dev, "Unable to enable AHB clock.\n");
goto err_pltfm_free;
}
ret = clk_prepare_enable(clk_xin);
if (ret) {
- dev_err(>dev, "Unable to enable SD clock.\n");
+ dev_err(dev, "Unable to enable SD clock.\n");
goto clk_dis_ahb;
}
@@ -1573,7 +1574,7 @@ static int sdhci_arasan_probe(struct platform_device
*pdev)
pltfm_host->clk = clk_xin;
- if (of_device_is_compatible(pdev->dev.of_node,
+ if (of_device_is_compatible(dev->of_node,
"rockchip,rk3399-sdhci-5.1"))
sdhci_arasan_update_clockmultiplier(host, 0x0);
@@ -1588,7 +1589,7 @@ static int sdhci_arasan_probe(struct platform_device
*pdev)
sdhci_arasan_update_baseclkfreq(host);
- ret = sdhci_arasan_register_sdclk(sdhci_arasan, clk_xin, >dev);
+ ret = sdhci_arasan_register_sdclk(sdhci_arasan, clk_xin, dev);
if (ret)
goto clk_disable_all;
@@ -1597,29 +1598,28 @@ static int sdhci_arasan_probe(struct platform_device
*pdev)
arasan_zynqmp_execute_tuning;
}
- arasan_dt_parse_clk_phases(>dev, _arasan->clk_data);
+ arasan_dt_parse_clk_phases(dev, _arasan->clk_data);
ret = mmc_of_parse(host->mmc);
if (ret) {
if (ret != -EPROBE_DEFER)
- dev_err(>dev, "parsing dt failed (%d)\n", ret);
+ dev_err(dev, "parsing dt failed (%d)\n", ret);
goto unreg_clk;
}
sdhci_arasan->phy = ERR_PTR(-ENODEV);
- if (of_device_is_compatible(pdev->dev.of_node,
+ if (of_device_is_compatible(dev->of_node,
"arasan,sdhci-5.1")) {
- sdhci_arasan->phy = devm_phy_get(>dev,
-"phy_arasan");
+ sdhci_arasan->phy = devm_phy_get(dev, "phy_arasan");
if (IS_ERR(sdhci_arasan->phy)) {
ret = PTR_ERR(sdhci_arasan->phy);
- dev_err(>dev, "No phy for
[PATCH v6 0/4] mmc: sdhci-of-arasan: Enable UHS-1 support for Keem Bay SOC
From: Muhammad Husaini Zulkifli Hello This patch series adds UHS-1 Support for Keem Bay SOC. Patch 1 : Add struct device *dev in probe func(),so that dev pointer can be widely use in probe to make code more readable. Patch 2 : Export function to be use by device driver to configure voltage rail output. Patch 3 : Defined the DT binding to support the UHS-1 operation. Patch 4 : Gives an overview of how voltage operations happen to support UHS-1 mode for Keem Bay SOC. All of these patches was tested with Keem Bay evaluation module board. Kindly help to review this patch set. Thank you. Changes since v5: - Restructured voltage operation for io bus line in one function and added comments in sdhci-of-arasan.c. - Use gpio regulator modelling for expander pins. - Add DT Bindings for phys, vmmc and vqmmc supplies. - Renamed func name and added comments for firmware header files. - Update commit message for each patchs to describe what goes on. Changes since v4: - Fixed comment by Andy and Sudeep on first patch. - Add Acked-by tag. - Fixed comment by Michal and Andy on the third patch to replace current users of >dev. Changes since v3: - Add Dt bindings for uhs gpio. - Fixed comment by Michal and Sudeep on header file for the macro and error code. - Fixed comment by Andy and created 1 new patch to separate the struc dev pointer in probe func. - Fixed comment by Michal in arasan controller code. Changes since v2: - Removed Document DT Bindings for Keembay Firmware. - Removed Firmware Driver to handle ATF Service call. - Add header file to handle API function for device driver to communicate with Arm Trusted Firmware. Changes since v1: - Add Document DT Bindings for Keembay Firmware. - Created Firmware Driver to handle ATF Service call. - Provide API for arasan driver for sd card voltage changes. Muhammad Husaini Zulkifli (4): mmc: sdhci-of-arasan: Add structure device pointer in probe func firmware: keembay: Add support for Trusted Firmware Service call dt-bindings: mmc: Add phys, vmmc and vqmmc supplies for Keem Bay SOC mmc: sdhci-of-arasan: Enable UHS-1 support for Keem Bay SOC .../devicetree/bindings/mmc/arasan,sdhci.yaml | 6 +- drivers/mmc/host/sdhci-of-arasan.c| 282 -- include/linux/firmware/intel/keembay.h| 54 3 files changed, 322 insertions(+), 20 deletions(-) create mode 100644 include/linux/firmware/intel/keembay.h -- 2.17.1
Re: [PATCH v2 3/3] edac: Supporting AST2400 and AST2600 edac driver
On Wed, 2 Dec 2020 at 06:37, Troy Lee wrote:
>
> Adding AST2400 and AST2600 edac driver support.
>
> Signed-off-by: Troy Lee
> ---
> Change since v1:
> 1. Removing SoC specific code
> 2. Changing numerical representation of memory sizing
> ---
> drivers/edac/Kconfig | 6 +--
> drivers/edac/aspeed_edac.c | 103 +
> 2 files changed, 85 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index fc30f2ef9782..8ea70746d0bf 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -508,10 +508,10 @@ config EDAC_QCOM
> health, you should probably say 'Y' here.
>
> config EDAC_ASPEED
> - tristate "Aspeed AST 2500 SoC"
> - depends on MACH_ASPEED_G5
> + tristate "Aspeed AST BMC SoC"
> + depends on (MACH_ASPEED_G4 || MACH_ASPEED_G5 || MACH_ASPEED_G6)
Change this to ARCH_ASPEED.
> help
> - Support for error detection and correction on the Aspeed AST 2500
> SoC.
> + Support for error detection and correction on the Aspeed AST BMC
> SoC.
>
> First, ECC must be configured in the bootloader. Then, this driver
> will expose error counters via the EDAC kernel framework.
> diff --git a/drivers/edac/aspeed_edac.c b/drivers/edac/aspeed_edac.c
> index fbec28dc661d..b8c8d6a05f91 100644
> --- a/drivers/edac/aspeed_edac.c
> +++ b/drivers/edac/aspeed_edac.c
> @@ -14,12 +14,11 @@
> #include
> #include "edac_module.h"
>
> -
These whitespace cleanups are ok, but can probably go in a different
patch so they aren't mixed up with the functional changes.
> #define DRV_NAME "aspeed-edac"
>
> -
> #define ASPEED_MCR_PROT0x00 /* protection key register */
> #define ASPEED_MCR_CONF0x04 /* configuration register */
> +#define ASPEED_MCR_REQ 0x08 /* Graphics Memory Protection register */
> #define ASPEED_MCR_INTR_CTRL 0x50 /* interrupt control/status register */
> #define ASPEED_MCR_ADDR_UNREC 0x58 /* address of first un-recoverable error
> */
> #define ASPEED_MCR_ADDR_REC0x5c /* address of last recoverable error */
> @@ -29,15 +28,17 @@
> #define ASPEED_MCR_PROT_PASSWD 0xfc600309
> #define ASPEED_MCR_CONF_DRAM_TYPE BIT(4)
> #define ASPEED_MCR_CONF_ECC BIT(7)
> +#define ASPEED_MCR_CONF_DRAM_CTRL_TYPE (BIT(28)|BIT(29)|BIT(30)|BIT(31))
We can use GENMASK here:
GENMASK(31, 28)
> #define ASPEED_MCR_INTR_CTRL_CLEAR BIT(31)
> #define ASPEED_MCR_INTR_CTRL_CNT_REC GENMASK(23, 16)
> #define ASPEED_MCR_INTR_CTRL_CNT_UNREC GENMASK(15, 12)
> #define ASPEED_MCR_INTR_CTRL_ENABLE (BIT(0) | BIT(1))
>
> +#define ASPEED_MCR_CONF_DRAM_CTRL_TYPE_AST2500 0x01
> +#define ASPEED_MCR_CONF_DRAM_CTRL_TYPE_AST2600 0x03
>
> static struct regmap *aspeed_regmap;
>
> -
> static int regmap_reg_write(void *context, unsigned int reg, unsigned int
> val)
> {
> void __iomem *regs = (void __iomem *)context;
> @@ -53,7 +54,6 @@ static int regmap_reg_write(void *context, unsigned int
> reg, unsigned int val)
> return 0;
> }
>
> -
> static int regmap_reg_read(void *context, unsigned int reg, unsigned int
> *val)
> {
> void __iomem *regs = (void __iomem *)context;
> @@ -63,6 +63,79 @@ static int regmap_reg_read(void *context, unsigned int
> reg, unsigned int *val)
> return 0;
> }
>
> +extern void aspeed_sdmc_disable_mem_protection(u8 req)
> +{
> + u32 req_val = 0;
> +
> + regmap_read(aspeed_regmap, ASPEED_MCR_REQ, _val);
> +
> + req_val &= ~BIT(req);
> +
> + regmap_write(aspeed_regmap, ASPEED_MCR_REQ, req_val);
This is open coding regmap_update_bits:
regmap_update_bits(aspeed_regmap, ASPEED_MCR_REQ, BIT(req), BIT(req));
> +}
> +EXPORT_SYMBOL(aspeed_sdmc_disable_mem_protection);
I don't think any of these functions need to be exported. The same
comment applies to the functions below this one; you can make them all
static and drop the extern and the EXPORT_SYMBOL.
> +
> +static const u32 ast2400_dram_table[] = {
> + 64 << 20,
> + 128 << 20,
> + 256 << 20,
> + 512 << 20,
> +};
> +
> +static const u32 ast2500_dram_table[] = {
> + 128 << 20,
> + 256 << 20,
> + 512 << 20,
> + 1024 << 20,
> +};
> +
> +static const u32 ast2600_dram_table[] = {
> + 256 << 20,
> + 512 << 20,
> + 1024 << 20,
> + 2048 << 20,
> +};
> +
> +extern u32 aspeed_get_dram_size(void)
> +{
> + u32 reg04;
> + u32 size;
> + u8 type;
> +
> + regmap_read(aspeed_regmap, ASPEED_MCR_CONF, );
> +
> + type = (reg04 & ASPEED_MCR_CONF_DRAM_CTRL_TYPE) >> 28;
> +
> + if (type == ASPEED_MCR_CONF_DRAM_CTRL_TYPE_AST2600)
> + size = ast2600_dram_table[reg04 & 0x3];
> + else if (type == ASPEED_MCR_CONF_DRAM_CTRL_TYPE_AST2500)
> + size = ast2500_dram_table[reg04 & 0x3];
> + else
> + size = ast2400_dram_table[reg04 &
[PATCH v2 4/4] misc: rtsx: rts5249 support runtime PM
From: Ricky Wu
rtsx_pcr:
add callback functions to support runtime PM
add delay_work to put device to D3 after idle
over 10 sec
rts5249:
add extra init flow for rtd3 and set rtd3_en from
config setting
rtsx_pci_sdmmc:
child device support autosuspend
Signed-off-by: Ricky Wu
---
drivers/misc/cardreader/rts5249.c | 26 +--
drivers/misc/cardreader/rtsx_pcr.c | 106 -
drivers/misc/cardreader/rtsx_pcr.h | 1 +
drivers/mmc/host/rtsx_pci_sdmmc.c | 16 +
include/linux/rtsx_pci.h | 2 +
5 files changed, 145 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/cardreader/rts5249.c
b/drivers/misc/cardreader/rts5249.c
index b85279f1fc5e..b2676e7f5027 100644
--- a/drivers/misc/cardreader/rts5249.c
+++ b/drivers/misc/cardreader/rts5249.c
@@ -73,6 +73,9 @@ static void rtsx_base_fetch_vendor_settings(struct rtsx_pcr
*pcr)
pci_read_config_dword(pdev, PCR_SETTING_REG2, );
pcr_dbg(pcr, "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG2, reg);
+
+ pcr->rtd3_en = rtsx_reg_to_rtd3_uhsii(reg);
+
if (rtsx_check_mmc_support(reg))
pcr->extra_caps |= EXTRA_CAPS_NO_MMC;
pcr->sd30_drive_sel_3v3 = rtsx_reg_to_sd30_drive_sel_3v3(reg);
@@ -278,15 +281,28 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
rtsx_pci_send_cmd(pcr, CMD_TIMEOUT_DEF);
- if (CHK_PCI_PID(pcr, PID_524A) || CHK_PCI_PID(pcr, PID_525A)) {
+ if (CHK_PCI_PID(pcr, PID_524A) || CHK_PCI_PID(pcr, PID_525A))
rtsx_pci_write_register(pcr, REG_VREF, PWD_SUSPND_EN,
PWD_SUSPND_EN);
- rtsx_pci_write_register(pcr, RTS524A_PM_CTRL3, 0x01, 0x00);
- rtsx_pci_write_register(pcr, RTS524A_PME_FORCE_CTL, 0x30, 0x20);
+
+ if (pcr->rtd3_en) {
+ if (CHK_PCI_PID(pcr, PID_524A) || CHK_PCI_PID(pcr, PID_525A)) {
+ rtsx_pci_write_register(pcr, RTS524A_PM_CTRL3, 0x01,
0x01);
+ rtsx_pci_write_register(pcr, RTS524A_PME_FORCE_CTL,
0x30, 0x30);
+ } else {
+ rtsx_pci_write_register(pcr, PM_CTRL3, 0x01, 0x01);
+ rtsx_pci_write_register(pcr, PME_FORCE_CTL, 0xFF, 0x33);
+ }
} else {
- rtsx_pci_write_register(pcr, PME_FORCE_CTL, 0xFF, 0x30);
- rtsx_pci_write_register(pcr, PM_CTRL3, 0x01, 0x00);
+ if (CHK_PCI_PID(pcr, PID_524A) || CHK_PCI_PID(pcr, PID_525A)) {
+ rtsx_pci_write_register(pcr, RTS524A_PM_CTRL3, 0x01,
0x00);
+ rtsx_pci_write_register(pcr, RTS524A_PME_FORCE_CTL,
0x30, 0x20);
+ } else {
+ rtsx_pci_write_register(pcr, PME_FORCE_CTL, 0xFF, 0x30);
+ rtsx_pci_write_register(pcr, PM_CTRL3, 0x01, 0x00);
+ }
}
+
/*
* If u_force_clkreq_0 is enabled, CLKREQ# PIN will be forced
* to drive low, and we forcibly request clock.
diff --git a/drivers/misc/cardreader/rtsx_pcr.c
b/drivers/misc/cardreader/rtsx_pcr.c
index 3612063cab09..2700d1997750 100644
--- a/drivers/misc/cardreader/rtsx_pcr.c
+++ b/drivers/misc/cardreader/rtsx_pcr.c
@@ -20,6 +20,8 @@
#include
#include
#include
+#include
+#include
#include "rtsx_pcr.h"
#include "rts5261.h"
@@ -150,6 +152,12 @@ void rtsx_pci_start_run(struct rtsx_pcr *pcr)
if (pcr->remove_pci)
return;
+ if (pcr->rtd3_en)
+ if (pcr->is_runtime_suspended) {
+ pm_runtime_get(&(pcr->pci->dev));
+ pcr->is_runtime_suspended = false;
+ }
+
if (pcr->state != PDEV_STAT_RUN) {
pcr->state = PDEV_STAT_RUN;
if (pcr->ops->enable_auto_blink)
@@ -1081,6 +1089,16 @@ static void rtsx_pm_power_saving(struct rtsx_pcr *pcr)
rtsx_comm_pm_power_saving(pcr);
}
+static void rtsx_pci_rtd3_work(struct work_struct *work)
+{
+ struct delayed_work *dwork = to_delayed_work(work);
+ struct rtsx_pcr *pcr = container_of(dwork, struct rtsx_pcr, rtd3_work);
+
+ pcr_dbg(pcr, "--> %s\n", __func__);
+ if (!pcr->is_runtime_suspended)
+ pm_runtime_put(&(pcr->pci->dev));
+}
+
static void rtsx_pci_idle_work(struct work_struct *work)
{
struct delayed_work *dwork = to_delayed_work(work);
@@ -1100,6 +1118,9 @@ static void rtsx_pci_idle_work(struct work_struct *work)
rtsx_pm_power_saving(pcr);
mutex_unlock(>pcr_mutex);
+
+ if (pcr->rtd3_en)
+ mod_delayed_work(system_wq, >rtd3_work,
msecs_to_jiffies(1));
}
static void rtsx_base_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
@@ -1579,6 +1600,15 @@ static int rtsx_pci_probe(struct pci_dev *pcidev,
rtsx_pcr_cells[i].platform_data = handle;
rtsx_pcr_cells[i].pdata_size = sizeof(*handle);
}
+
+ if (pcr->rtd3_en) {
+
[PATCH net-next] octeontx2-af: debugfs: delete dead code
These debugfs never return NULL so all this code will never be run.
In the normal case, (and in this case particularly), the debugfs
functions are not supposed to be checked for errors so all this error
checking code can be safely deleted.
Signed-off-by: Dan Carpenter
---
.../marvell/octeontx2/af/rvu_debugfs.c| 255 --
1 file changed, 52 insertions(+), 203 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
index c383efc6b90c..d27543c1a166 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
@@ -1368,119 +1368,52 @@ RVU_DEBUG_SEQ_FOPS(nix_qsize, nix_qsize_display,
nix_qsize_write);
static void rvu_dbg_nix_init(struct rvu *rvu, int blkaddr)
{
- const struct device *dev = >pdev->dev;
struct nix_hw *nix_hw;
- struct dentry *pfile;
if (!is_block_implemented(rvu->hw, blkaddr))
return;
if (blkaddr == BLKADDR_NIX0) {
rvu->rvu_dbg.nix = debugfs_create_dir("nix", rvu->rvu_dbg.root);
- if (!rvu->rvu_dbg.nix) {
- dev_err(rvu->dev, "create debugfs dir failed for
nix\n");
- return;
- }
nix_hw = >hw->nix[0];
} else {
rvu->rvu_dbg.nix = debugfs_create_dir("nix1",
rvu->rvu_dbg.root);
- if (!rvu->rvu_dbg.nix) {
- dev_err(rvu->dev,
- "create debugfs dir failed for nix1\n");
- return;
- }
nix_hw = >hw->nix[1];
}
- pfile = debugfs_create_file("sq_ctx", 0600, rvu->rvu_dbg.nix, nix_hw,
- _dbg_nix_sq_ctx_fops);
- if (!pfile)
- goto create_failed;
-
- pfile = debugfs_create_file("rq_ctx", 0600, rvu->rvu_dbg.nix, nix_hw,
- _dbg_nix_rq_ctx_fops);
- if (!pfile)
- goto create_failed;
-
- pfile = debugfs_create_file("cq_ctx", 0600, rvu->rvu_dbg.nix, nix_hw,
- _dbg_nix_cq_ctx_fops);
- if (!pfile)
- goto create_failed;
-
- pfile = debugfs_create_file("ndc_tx_cache", 0600, rvu->rvu_dbg.nix,
- nix_hw, _dbg_nix_ndc_tx_cache_fops);
- if (!pfile)
- goto create_failed;
-
- pfile = debugfs_create_file("ndc_rx_cache", 0600, rvu->rvu_dbg.nix,
- nix_hw, _dbg_nix_ndc_rx_cache_fops);
- if (!pfile)
- goto create_failed;
-
- pfile = debugfs_create_file("ndc_tx_hits_miss", 0600, rvu->rvu_dbg.nix,
- nix_hw,
- _dbg_nix_ndc_tx_hits_miss_fops);
- if (!pfile)
- goto create_failed;
-
- pfile = debugfs_create_file("ndc_rx_hits_miss", 0600, rvu->rvu_dbg.nix,
- nix_hw,
- _dbg_nix_ndc_rx_hits_miss_fops);
- if (!pfile)
- goto create_failed;
-
- pfile = debugfs_create_file("qsize", 0600, rvu->rvu_dbg.nix, rvu,
- _dbg_nix_qsize_fops);
- if (!pfile)
- goto create_failed;
-
- return;
-create_failed:
- dev_err(dev,
- "Failed to create debugfs dir/file for NIX blk\n");
- debugfs_remove_recursive(rvu->rvu_dbg.nix);
+ debugfs_create_file("sq_ctx", 0600, rvu->rvu_dbg.nix, nix_hw,
+ _dbg_nix_sq_ctx_fops);
+ debugfs_create_file("rq_ctx", 0600, rvu->rvu_dbg.nix, nix_hw,
+ _dbg_nix_rq_ctx_fops);
+ debugfs_create_file("cq_ctx", 0600, rvu->rvu_dbg.nix, nix_hw,
+ _dbg_nix_cq_ctx_fops);
+ debugfs_create_file("ndc_tx_cache", 0600, rvu->rvu_dbg.nix, nix_hw,
+ _dbg_nix_ndc_tx_cache_fops);
+ debugfs_create_file("ndc_rx_cache", 0600, rvu->rvu_dbg.nix, nix_hw,
+ _dbg_nix_ndc_rx_cache_fops);
+ debugfs_create_file("ndc_tx_hits_miss", 0600, rvu->rvu_dbg.nix, nix_hw,
+ _dbg_nix_ndc_tx_hits_miss_fops);
+ debugfs_create_file("ndc_rx_hits_miss", 0600, rvu->rvu_dbg.nix, nix_hw,
+ _dbg_nix_ndc_rx_hits_miss_fops);
+ debugfs_create_file("qsize", 0600, rvu->rvu_dbg.nix, rvu,
+ _dbg_nix_qsize_fops);
}
static void rvu_dbg_npa_init(struct rvu *rvu)
{
- const struct device *dev = >pdev->dev;
- struct dentry *pfile;
-
rvu->rvu_dbg.npa = debugfs_create_dir("npa", rvu->rvu_dbg.root);
- if (!rvu->rvu_dbg.npa)
- return;
-
- pfile = debugfs_create_file("qsize", 0600,
[PATCH] platform/x86: dell-wmi-sysman: work around for BIOS bug
BIOS sets incorrect value (zero) when SET value passed for integer attribute
with + sign. Added workaround to remove + sign before passing input to BIOS
Co-developed-by: Mario Limonciello
Signed-off-by: Mario Limonciello
Co-developed-by: Prasanth KSR
Signed-off-by: Prasanth KSR
Signed-off-by: Divya Bharathi
---
drivers/platform/x86/dell-wmi-sysman/int-attributes.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/dell-wmi-sysman/int-attributes.c
b/drivers/platform/x86/dell-wmi-sysman/int-attributes.c
index ea773d8e8d3a..f30d155135c3 100644
--- a/drivers/platform/x86/dell-wmi-sysman/int-attributes.c
+++ b/drivers/platform/x86/dell-wmi-sysman/int-attributes.c
@@ -39,7 +39,7 @@ static ssize_t current_value_show(struct kobject *kobj,
struct kobj_attribute *a
* @instance_id: The instance on which input is validated
* @buf: Input value
*/
-static int validate_integer_input(int instance_id, const char *buf)
+static int validate_integer_input(int instance_id, char *buf)
{
int in_val;
int ret;
@@ -51,6 +51,12 @@ static int validate_integer_input(int instance_id, const
char *buf)
in_val > wmi_priv.integer_data[instance_id].max_value)
return -EINVAL;
+ /* workaround for BIOS error.
+* validate input to avoid setting 0 when integer input passed with +
sign
+*/
+ if (*buf == '+')
+ memmove(buf, (buf + 1), strlen(buf));
+
return ret;
}
--
2.25.1
Re: [PATCH v4 5/5] perf metric: Don't compute unused events.
> Can't this be all in a macro? It's still a lot of duplication. > > I'm still not a fan, but I think with a macro it wouldn't be too bad. > >Ugh, not a fan of macros. They expand to a single line of code and make >debugging hard. I'll do a v5 with a macro :-/ I suppose you could inlines with callbacks too, with one liner functions for the operands. -Andi
[PATCH] mm/vmalloc: Remove unnecessary return statement
Remove unnecessary return statement for void function. Signed-off-by: Baolin Wang --- mm/vmalloc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 6ae491a..c290fc9 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2275,7 +2275,6 @@ static void __vunmap(const void *addr, int deallocate_pages) } kfree(area); - return; } static inline void __vfree_deferred(const void *addr) -- 1.8.3.1
[PATCH v2] phy: samsung: Merge Kconfig for Exynos5420 and Exynos5250
Exynos5420 variant of USB2 PHY is handled by the same code as the
Exynos5250 one. Introducing a separate Kconfig symbol for it was an
over-engineering, which turned out to cause build break for certain
configurations:
ERROR: modpost: "exynos5420_usb2_phy_config"
[drivers/phy/samsung/phy-exynos-usb2.ko] undefined!
Fix this by removing PHY_EXYNOS5420_USB2 symbol and using
PHY_EXYNOS5250_USB2 also for Exynos5420 SoCs.
Reported-by: Markus Reichl
Fixes: 81b534f7e9b2 ("phy: samsung: Add support for the Exynos5420 variant of
the USB2 PHY")
Signed-off-by: Marek Szyprowski
Acked-by: Krzysztof Kozlowski
Reviewed-by: Jaehoon Chung
---
v2:
- reworded subject
---
drivers/phy/samsung/Kconfig| 7 +--
drivers/phy/samsung/phy-samsung-usb2.c | 2 --
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/phy/samsung/Kconfig b/drivers/phy/samsung/Kconfig
index 0f51d3bf38cc..e20d2fcc9fe7 100644
--- a/drivers/phy/samsung/Kconfig
+++ b/drivers/phy/samsung/Kconfig
@@ -64,12 +64,7 @@ config PHY_EXYNOS4X12_USB2
config PHY_EXYNOS5250_USB2
bool
depends on PHY_SAMSUNG_USB2
- default SOC_EXYNOS5250
-
-config PHY_EXYNOS5420_USB2
- bool
- depends on PHY_SAMSUNG_USB2
- default SOC_EXYNOS5420
+ default SOC_EXYNOS5250 || SOC_EXYNOS5420
config PHY_S5PV210_USB2
bool "Support for S5PV210"
diff --git a/drivers/phy/samsung/phy-samsung-usb2.c
b/drivers/phy/samsung/phy-samsung-usb2.c
index 3908153f2ce5..ec2befabeea6 100644
--- a/drivers/phy/samsung/phy-samsung-usb2.c
+++ b/drivers/phy/samsung/phy-samsung-usb2.c
@@ -127,8 +127,6 @@ static const struct of_device_id
samsung_usb2_phy_of_match[] = {
.compatible = "samsung,exynos5250-usb2-phy",
.data = _usb2_phy_config,
},
-#endif
-#ifdef CONFIG_PHY_EXYNOS5420_USB2
{
.compatible = "samsung,exynos5420-usb2-phy",
.data = _usb2_phy_config,
--
2.17.1
[PATCH] pstore: Tidy up an error check
The crypto_alloc_comp() function never returns NULL, it returns error
pointers on error.
Signed-off-by: Dan Carpenter
---
fs/pstore/platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 36714df37d5d..b7a2a2a31dee 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -315,7 +315,7 @@ static void allocate_buf_for_compression(void)
}
ctx = crypto_alloc_comp(zbackend->name, 0, 0);
- if (IS_ERR_OR_NULL(ctx)) {
+ if (IS_ERR(ctx)) {
kfree(buf);
pr_err("crypto_alloc_comp('%s') failed: %ld\n", zbackend->name,
PTR_ERR(ctx));
--
2.29.2
Re: [RFC V2 0/3] mm/hotplug: Pre-validate the address range with platform
On 11/30/20 8:59 AM, Anshuman Khandual wrote: > This series adds a mechanism allowing platforms to weigh in and prevalidate > incoming address range before proceeding further with the memory hotplug. > This helps prevent potential platform errors for the given address range, > down the hotplug call chain, which inevitably fails the hotplug itself. > > This mechanism was suggested by David Hildenbrand during another discussion > with respect to a memory hotplug fix on arm64 platform. > > https://lore.kernel.org/linux-arm-kernel/1600332402-30123-1-git-send-email-anshuman.khand...@arm.com/ > > This mechanism focuses on the addressibility aspect and not [sub] section > alignment aspect. Hence check_hotplug_memory_range() and check_pfn_span() > have been left unchanged. Wondering if all these can still be unified in > an expanded memhp_range_allowed() check, that can be called from multiple > memory hot add and remove paths. > > This series applies on v5.10-rc6 and has been slightly tested on arm64. > But looking for some early feedback here. > > Changes in RFC V2: > > Incorporated all review feedbacks from David. > > - Added additional range check in __segment_load() on s390 which was lost > - Changed is_private init in pagemap_range() > - Moved the framework into mm/memory_hotplug.c > - Made arch_get_addressable_range() a __weak function > - Renamed arch_get_addressable_range() as arch_get_mappable_range() > - Callback arch_get_mappable_range() only handles range requiring linear > mapping > - Merged multiple memhp_range_allowed() checks in register_memory_resource() > - Replaced WARN() with pr_warn() in memhp_range_allowed() > - Replaced error return code ERANGE with E2BIG There is one build failure with MEMORY_HOTPLUG=y and MEMORY_HOTREMOVE=n. There are warnings on arm64 and s390 platforms when built with W=1 due to lack of prototypes required with -Wmissing-prototypes. I have fixed all these problems for the next iteration when there is broad agreement on the overall approach.
[PATCH] ACPI: Add DMI quirk for GIGABYTE GB-BXBT-2807
From: "Jasper St. Pierre"
The GIGABYTE GB-BXBT-2807 is a mini-PC which uses off the shelf
components, like an Intel GPU which is meant for mobile systems.
As such, it, by default, has a backlight controller exposed.
Unfortunately, the backlight controller only confuses userspace, which
sees the existence of a backlight device node and has the unrealistic
belief that there is actually a backlight there!
Add a DMI quirk to force the backlight off on this system.
Signed-off-by: Jasper St. Pierre
Reviewed-by: Chris Chiu
---
drivers/acpi/video_detect.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 2499d7e3c710..ac2e194acdbf 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -143,6 +143,13 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
},
{
.callback = video_detect_force_vendor,
+ .ident = "GIGABYTE GB-BXBT-2807",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
+ },
+ },
+ {
.ident = "Sony VPCEH3U1E",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
--
2.20.1
Re: [PATCH v2 1/3] dt-bindings: edac: aspeed-sdram-edac: Add ast2400/ast2600 support
On Wed, 2 Dec 2020 at 06:37, Troy Lee wrote: > > Adding Aspeed AST2400 and AST2600 binding for edac driver. > > Signed-off-by: Troy Lee Acked-by: Joel Stanley > --- > .../devicetree/bindings/edac/aspeed-sdram-edac.txt | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt > b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt > index 6a0f3d90d682..8ca9e0a049d8 100644 > --- a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt > +++ b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt > @@ -1,6 +1,6 @@ > -Aspeed AST2500 SoC EDAC node > +Aspeed BMC SoC EDAC node > > -The Aspeed AST2500 SoC supports DDR3 and DDR4 memory with and without ECC > (error > +The Aspeed BMC SoC supports DDR3 and DDR4 memory with and without ECC (error > correction check). > > The memory controller supports SECDED (single bit error correction, double > bit > @@ -11,7 +11,10 @@ Note, the bootloader must configure ECC mode in the memory > controller. > > > Required properties: > -- compatible: should be "aspeed,ast2500-sdram-edac" > +- compatible: should be one of > + - "aspeed,ast2400-sdram-edac" > + - "aspeed,ast2500-sdram-edac" > + - "aspeed,ast2600-sdram-edac" > - reg:sdram controller register set should be <0x1e6e 0x174> > - interrupts: should be AVIC interrupt #0 > > -- > 2.17.1 >
Re: [f2fs-dev] [PATCH v2 2/2] f2fs: add F2FS_IOC_DECOMPRESS_FILE and F2FS_IOC_COMPRESS_FILE
On 2020/12/1 12:08, Daeho Jeong wrote:
From: Daeho Jeong
Added two ioctl to decompress/compress explicitly the compression
enabled file in "compress_mode=user" mount option.
Using these two ioctls, the users can make a control of compression
and decompression of their files.
Signed-off-by: Daeho Jeong
---
v2: reformed codes based on comments and put gradual flush routine
---
fs/f2fs/file.c| 185 ++
include/uapi/linux/f2fs.h | 2 +
2 files changed, 187 insertions(+)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index be8db06aca27..300355fe25f0 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -4026,6 +4026,185 @@ static int f2fs_ioc_set_compress_option(struct file
*filp, unsigned long arg)
return ret;
}
+static int redirty_blocks(struct inode *inode, pgoff_t page_idx, int len)
+{
+ DEFINE_READAHEAD(ractl, NULL, inode->i_mapping, page_idx);
+ struct address_space *mapping = inode->i_mapping;
+ struct page *page;
+ pgoff_t redirty_idx = page_idx;
+ int i, page_len = 0, ret = 0;
+
+ page_cache_ra_unbounded(, len, 0);
+
+ for (i = 0; i < len; i++, page_idx++) {
+ page = read_cache_page(mapping, page_idx, NULL, NULL);
+ if (IS_ERR(page)) {
+ ret = PTR_ERR(page);
+ break;
+ }
+ page_len++;
+ }
+
+ for (i = 0; i < page_len; i++, redirty_idx++) {
+ page = find_lock_page(mapping, redirty_idx);
+ if (!page)
+ ret = -ENOENT;
+ set_page_dirty(page);
+ f2fs_put_page(page, 1);
+ f2fs_put_page(page, 0);
+ }
+
+ return ret;
+}
+
+static int f2fs_ioc_decompress_file(struct file *filp, unsigned long arg)
+{
+ struct inode *inode = file_inode(filp);
+ struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+ struct f2fs_inode_info *fi = F2FS_I(inode);
+ pgoff_t page_idx = 0, last_idx;
+ unsigned int blk_per_seg = sbi->blocks_per_seg, dirtied = 0;
+ int cluster_size = F2FS_I(inode)->i_cluster_size;
+ int count, ret;
+
+ if (!f2fs_sb_has_compression(sbi) ||
+ F2FS_OPTION(sbi).compress_mode != COMPR_MODE_USER)
+ return -EOPNOTSUPP;
+
+ if (!(filp->f_mode & FMODE_WRITE))
+ return -EBADF;
+
+ if (!f2fs_compressed_file(inode))
+ return -EINVAL;
+
+ if (!f2fs_is_compress_backend_ready(inode))
+ return -ENOPKG;
Oh, it looks there will be a race case with f2fs_ioc_set_compress_option(),
it needs to relocate this condition under inode lock.
In all other places, it will return -EOPNOTSUPP, how about keeping in line with
them?
+
+ f2fs_balance_fs(F2FS_I_SB(inode), true);
+
+ file_start_write(filp);
+ inode_lock(inode);
+
+ if (f2fs_is_mmap_file(inode)) {
+ ret = -EBUSY;
+ goto out;
+ }
+
+ ret = filemap_write_and_wait_range(inode->i_mapping, 0, LLONG_MAX);
+ if (ret)
+ goto out;
+
+ if (!atomic_read(>i_compr_blocks))
+ goto out;
+
+ last_idx = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE);
+
+ count = last_idx - page_idx;
+ while (count) {
+ int len = min(cluster_size, count);
+
+ ret = redirty_blocks(inode, page_idx, len);
+ if (ret < 0)
+ break;
+
+ count -= len;
+ page_idx += len;
+ dirtied += len;
use get_dirty_pages(inode) will be a little bit more accurate? as kworker is
running to writeback dirty pages in background.
+ if (dirtied >= blk_per_seg) {
+ filemap_fdatawrite(inode->i_mapping);
+ dirtied = 0;
+ }
+ }
+
+ if (!ret)
+ ret = filemap_write_and_wait_range(inode->i_mapping, 0,
+ LLONG_MAX);
+
+ if (ret)
+ f2fs_warn(sbi, "%s: The file might be partially decompressed "
+ "(errno=%d). Please delete the file.\n",
+ __func__, ret);
+out:
+ inode_unlock(inode);
+ file_end_write(filp);
+
+ return ret;
+}
+
+static int f2fs_ioc_compress_file(struct file *filp, unsigned long arg)
+{
+ struct inode *inode = file_inode(filp);
+ struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+ pgoff_t page_idx = 0, last_idx;
+ unsigned int blk_per_seg = sbi->blocks_per_seg, dirtied = 0;
+ int cluster_size = F2FS_I(inode)->i_cluster_size;
+ int count, ret;
+
+ if (!f2fs_sb_has_compression(sbi) ||
+ F2FS_OPTION(sbi).compress_mode != COMPR_MODE_USER)
+ return -EOPNOTSUPP;
+
+ if (!(filp->f_mode & FMODE_WRITE))
+ return -EBADF;
[PATCH v2 1/3] dt-bindings: edac: aspeed-sdram-edac: Add ast2400/ast2600 support
Adding Aspeed AST2400 and AST2600 binding for edac driver. Signed-off-by: Troy Lee --- .../devicetree/bindings/edac/aspeed-sdram-edac.txt | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt index 6a0f3d90d682..8ca9e0a049d8 100644 --- a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt +++ b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt @@ -1,6 +1,6 @@ -Aspeed AST2500 SoC EDAC node +Aspeed BMC SoC EDAC node -The Aspeed AST2500 SoC supports DDR3 and DDR4 memory with and without ECC (error +The Aspeed BMC SoC supports DDR3 and DDR4 memory with and without ECC (error correction check). The memory controller supports SECDED (single bit error correction, double bit @@ -11,7 +11,10 @@ Note, the bootloader must configure ECC mode in the memory controller. Required properties: -- compatible: should be "aspeed,ast2500-sdram-edac" +- compatible: should be one of + - "aspeed,ast2400-sdram-edac" + - "aspeed,ast2500-sdram-edac" + - "aspeed,ast2600-sdram-edac" - reg:sdram controller register set should be <0x1e6e 0x174> - interrupts: should be AVIC interrupt #0 -- 2.17.1
RE: [EXT] Re: [PATCH v2 1/2] mmc: Support kmsg dumper based on pstore/blk
>-Original Message-
>From: Kees Cook
>Sent: Wednesday, December 2, 2020 1:56 AM
>To: Bhaskara Budiredla
>Cc: ulf.hans...@linaro.org; ccr...@android.com; tony.l...@intel.com; Sunil
>Kovvuri Goutham ; linux-...@vger.kernel.org;
>linux-kernel@vger.kernel.org; outgoing2/-cover-letter.patch@mx0b-
>0016f401.pphosted.com
>Subject: [EXT] Re: [PATCH v2 1/2] mmc: Support kmsg dumper based on
>pstore/blk
>
>External Email
>
>--
>On Mon, Nov 23, 2020 at 04:49:24PM +0530, Bhaskara Budiredla wrote:
>> This patch introduces to mmcpstore. The functioning of mmcpstore is
>> similar to mtdpstore. mmcpstore works on FTL based flash devices
>> whereas mtdpstore works on raw flash devices. When the system crashes,
>> mmcpstore stores the kmsg panic and oops logs to a user specified MMC
>> device.
>>
>> It collects the details about the host MMC device through pstore/blk
>> "blkdev" parameter. The user can specify the MMC device in many ways
>> by checking in Documentation/admin-guide/pstore-blk.rst.
>>
>> The individual mmc host drivers have to define suitable polling
>> subroutines to write kmsg panic/oops logs through mmcpstore.
>>
>> Signed-off-by: Bhaskara Budiredla
>> ---
>> drivers/mmc/core/Kconfig | 15 +-
>> drivers/mmc/core/Makefile| 1 +
>> drivers/mmc/core/block.c | 19 +++
>> drivers/mmc/core/block.h | 9 ++
>> drivers/mmc/core/core.c | 24 +++
>> drivers/mmc/core/mmcpstore.c | 302
>+++
>> include/linux/mmc/core.h | 4 +
>> include/linux/mmc/host.h | 12 ++
>> 8 files changed, 385 insertions(+), 1 deletion(-) create mode 100644
>> drivers/mmc/core/mmcpstore.c
>>
>> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig index
>> c12fe13e4b14..505450a6ea2b 100644
>> --- a/drivers/mmc/core/Kconfig
>> +++ b/drivers/mmc/core/Kconfig
>> @@ -34,9 +34,23 @@ config PWRSEQ_SIMPLE
>>This driver can also be built as a module. If so, the module
>>will be called pwrseq_simple.
>>
>> +config MMC_PSTORE_BACKEND
>> +bool "Log panic/oops to a MMC buffer"
>> +depends on MMC_BLOCK
>> +default n
>
>"default n" is redundant and can be dropped.
Yes, I have removed it.
>
>> +help
>> + This option will let you create platform backend to store kmsg
>> + crash dumps to a user specified MMC device. This is primarily
>> + based on pstore/blk.
>> +
>> +config MMC_PSTORE
>> +tristate
>> +select PSTORE_BLK
>
>I don't understand why this is separate?
>
>> +
>> config MMC_BLOCK
>> tristate "MMC block device driver"
>> depends on BLOCK
>> +select MMC_PSTORE if MMC_PSTORE_BACKEND=y
>> default y
>> help
>>Say Y here to enable the MMC block device driver support.
>> @@ -80,4 +94,3 @@ config MMC_TEST
>>
>>This driver is only of interest to those developing or
>>testing a host driver. Most people should say N here.
>> -
>
>Why isn't this just written as:
>
>config MMC_PSTORE
> bool "Log panic/oops to a MMC buffer"
> depends on MMC_BLOCK
> select PSTORE_BLK
> help
> This option will let you create platform backend to store kmsg
> crash dumps to a user specified MMC device. This is primarily
> based on pstore/blk.
>
The idea was to compile MMC_PSTORE as part of MMC_BLOCK driver,
provided it is optionally enabled.
The above arrangement compiles MMC_PSTORE
as module: if (CONFIG_MMC_PSTORE_BACKEND == y && CONFIG_MMC_BLOCK == m)
as static: if (CONFIG_MMC_PSTORE_BACKEND == y && CONFIG_MMC_BLOCK == y)
>
>
>
>> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
>> index 95ffe008ebdf..7cb9a3af4827 100644
>> --- a/drivers/mmc/core/Makefile
>> +++ b/drivers/mmc/core/Makefile
>> @@ -16,5 +16,6 @@ obj-$(CONFIG_PWRSEQ_EMMC) +=
>pwrseq_emmc.o
>> mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
>> obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
>> mmc_block-objs := block.o queue.o
>> +mmc_block-$(CONFIG_MMC_PSTORE) += mmcpstore.o
>> obj-$(CONFIG_MMC_TEST) += mmc_test.o
>> obj-$(CONFIG_SDIO_UART) += sdio_uart.o
>> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index
>> 8d3df0be0355..ed012a91e3a3 100644
>> --- a/drivers/mmc/core/block.c
>> +++ b/drivers/mmc/core/block.c
>> @@ -2870,6 +2870,21 @@ static void mmc_blk_remove_debugfs(struct
>> mmc_card *card,
>>
>> #endif /* CONFIG_DEBUG_FS */
>>
>> +#if IS_ENABLED(CONFIG_MMC_PSTORE)
>> +sector_t mmc_blk_get_part(struct mmc_card *card, int part_num,
>> +sector_t *size) {
>> +struct mmc_blk_data *md = dev_get_drvdata(>dev);
>> +struct gendisk *disk = md->disk;
>> +struct disk_part_tbl *part_tbl = disk->part_tbl;
>> +
>> +if (part_num < 0 || part_num >= part_tbl->len)
>> +return 0;
>> +
>> +*size = part_tbl->part[part_num]->nr_sects << SECTOR_SHIFT;
>> +return
[PATCH v2 3/3] edac: Supporting AST2400 and AST2600 edac driver
Adding AST2400 and AST2600 edac driver support.
Signed-off-by: Troy Lee
---
Change since v1:
1. Removing SoC specific code
2. Changing numerical representation of memory sizing
---
drivers/edac/Kconfig | 6 +--
drivers/edac/aspeed_edac.c | 103 +
2 files changed, 85 insertions(+), 24 deletions(-)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index fc30f2ef9782..8ea70746d0bf 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -508,10 +508,10 @@ config EDAC_QCOM
health, you should probably say 'Y' here.
config EDAC_ASPEED
- tristate "Aspeed AST 2500 SoC"
- depends on MACH_ASPEED_G5
+ tristate "Aspeed AST BMC SoC"
+ depends on (MACH_ASPEED_G4 || MACH_ASPEED_G5 || MACH_ASPEED_G6)
help
- Support for error detection and correction on the Aspeed AST 2500 SoC.
+ Support for error detection and correction on the Aspeed AST BMC SoC.
First, ECC must be configured in the bootloader. Then, this driver
will expose error counters via the EDAC kernel framework.
diff --git a/drivers/edac/aspeed_edac.c b/drivers/edac/aspeed_edac.c
index fbec28dc661d..b8c8d6a05f91 100644
--- a/drivers/edac/aspeed_edac.c
+++ b/drivers/edac/aspeed_edac.c
@@ -14,12 +14,11 @@
#include
#include "edac_module.h"
-
#define DRV_NAME "aspeed-edac"
-
#define ASPEED_MCR_PROT0x00 /* protection key register */
#define ASPEED_MCR_CONF0x04 /* configuration register */
+#define ASPEED_MCR_REQ 0x08 /* Graphics Memory Protection register */
#define ASPEED_MCR_INTR_CTRL 0x50 /* interrupt control/status register */
#define ASPEED_MCR_ADDR_UNREC 0x58 /* address of first un-recoverable error */
#define ASPEED_MCR_ADDR_REC0x5c /* address of last recoverable error */
@@ -29,15 +28,17 @@
#define ASPEED_MCR_PROT_PASSWD 0xfc600309
#define ASPEED_MCR_CONF_DRAM_TYPE BIT(4)
#define ASPEED_MCR_CONF_ECC BIT(7)
+#define ASPEED_MCR_CONF_DRAM_CTRL_TYPE (BIT(28)|BIT(29)|BIT(30)|BIT(31))
#define ASPEED_MCR_INTR_CTRL_CLEAR BIT(31)
#define ASPEED_MCR_INTR_CTRL_CNT_REC GENMASK(23, 16)
#define ASPEED_MCR_INTR_CTRL_CNT_UNREC GENMASK(15, 12)
#define ASPEED_MCR_INTR_CTRL_ENABLE (BIT(0) | BIT(1))
+#define ASPEED_MCR_CONF_DRAM_CTRL_TYPE_AST2500 0x01
+#define ASPEED_MCR_CONF_DRAM_CTRL_TYPE_AST2600 0x03
static struct regmap *aspeed_regmap;
-
static int regmap_reg_write(void *context, unsigned int reg, unsigned int val)
{
void __iomem *regs = (void __iomem *)context;
@@ -53,7 +54,6 @@ static int regmap_reg_write(void *context, unsigned int reg,
unsigned int val)
return 0;
}
-
static int regmap_reg_read(void *context, unsigned int reg, unsigned int *val)
{
void __iomem *regs = (void __iomem *)context;
@@ -63,6 +63,79 @@ static int regmap_reg_read(void *context, unsigned int reg,
unsigned int *val)
return 0;
}
+extern void aspeed_sdmc_disable_mem_protection(u8 req)
+{
+ u32 req_val = 0;
+
+ regmap_read(aspeed_regmap, ASPEED_MCR_REQ, _val);
+
+ req_val &= ~BIT(req);
+
+ regmap_write(aspeed_regmap, ASPEED_MCR_REQ, req_val);
+}
+EXPORT_SYMBOL(aspeed_sdmc_disable_mem_protection);
+
+static const u32 ast2400_dram_table[] = {
+ 64 << 20,
+ 128 << 20,
+ 256 << 20,
+ 512 << 20,
+};
+
+static const u32 ast2500_dram_table[] = {
+ 128 << 20,
+ 256 << 20,
+ 512 << 20,
+ 1024 << 20,
+};
+
+static const u32 ast2600_dram_table[] = {
+ 256 << 20,
+ 512 << 20,
+ 1024 << 20,
+ 2048 << 20,
+};
+
+extern u32 aspeed_get_dram_size(void)
+{
+ u32 reg04;
+ u32 size;
+ u8 type;
+
+ regmap_read(aspeed_regmap, ASPEED_MCR_CONF, );
+
+ type = (reg04 & ASPEED_MCR_CONF_DRAM_CTRL_TYPE) >> 28;
+
+ if (type == ASPEED_MCR_CONF_DRAM_CTRL_TYPE_AST2600)
+ size = ast2600_dram_table[reg04 & 0x3];
+ else if (type == ASPEED_MCR_CONF_DRAM_CTRL_TYPE_AST2500)
+ size = ast2500_dram_table[reg04 & 0x3];
+ else
+ size = ast2400_dram_table[reg04 & 0x3];
+
+ return size;
+}
+EXPORT_SYMBOL(aspeed_get_dram_size);
+
+static const u32 aspeed_vga_table[] = {
+ 8 << 20,
+ 16 << 20,
+ 32 << 20,
+ 64 << 20,
+};
+
+extern u32 aspeed_get_vga_size(void)
+{
+ u32 reg04;
+ u32 size;
+
+ regmap_read(aspeed_regmap, ASPEED_MCR_CONF, );
+
+ size = aspeed_vga_table[((reg04 & 0xC) >> 2)];
+ return size;
+}
+EXPORT_SYMBOL(aspeed_get_vga_size);
+
static bool regmap_is_volatile(struct device *dev, unsigned int reg)
{
switch (reg) {
@@ -227,7 +300,6 @@ static int config_irq(void *ctx, struct platform_device
*pdev)
return 0;
}
-
static int init_csrows(struct mem_ctl_info *mci)
{
struct csrow_info *csrow = mci->csrows[0];
@@ -239,7 +311,7 @@ static int init_csrows(struct
[PATCH v2 2/3] ARM: dts: aspeed: Add AST2600 edac into common devicetree
Adding Aspeed AST2600 edac node into common devicetree.
Signed-off-by: Troy Lee
---
arch/arm/boot/dts/aspeed-g6.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index 97ca743363d7..fb144515f397 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -69,6 +69,12 @@
always-on;
};
+ edac: sdram@1e6e {
+ compatible = "aspeed,ast2600-sdram-edac", "syscon";
+ reg = <0x1e6e 0x174>;
+ interrupts = ;
+ };
+
ahb {
compatible = "simple-bus";
#address-cells = <1>;
--
2.17.1
Re: [PATCH v4 5/5] perf metric: Don't compute unused events.
> +| expr '-' expr
> +{
> + if (!compute_ids || (is_const($1.val) && is_const($3.val))) {
> + assert($1.ids == NULL);
> + assert($3.ids == NULL);
> + $$.val = $1.val - $3.val;
> + $$.ids = NULL;
> + } else {
> + /* LHS and/or RHS need computing from event IDs so union. */
> + $$ = union_expr($1, $3);
> + }
Can't this be all in a macro? It's still a lot of duplication.
I'm still not a fan, but I think with a macro it wouldn't be too bad.
-Andi
[PATCH v2 3/4] mmc: rtsx: fix sdmmc_switch_voltage return bug
From: Ricky Wu fixed bug: return err always return rtsx_pci_write_register() return code not for callback function _switch_voltage() Signed-off-by: Ricky Wu --- drivers/mmc/host/rtsx_pci_sdmmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c b/drivers/mmc/host/rtsx_pci_sdmmc.c index eb395e144207..93be9fa97098 100644 --- a/drivers/mmc/host/rtsx_pci_sdmmc.c +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c @@ -1249,7 +1249,7 @@ static int sdmmc_switch_voltage(struct mmc_host *mmc, struct mmc_ios *ios) out: /* Stop toggle SD clock in idle */ - err = rtsx_pci_write_register(pcr, SD_BUS_STAT, + rtsx_pci_write_register(pcr, SD_BUS_STAT, SD_CLK_TOGGLE_EN | SD_CLK_FORCE_STOP, 0); mutex_unlock(>pcr_mutex); -- 2.17.1
Re: [PATCH -tip 22/32] sched: Split the cookie and setup per-task cookie on fork
On Tue, Dec 1, 2020 at 11:35 AM Peter Zijlstra wrote: > > So I don't think that later patch is right... That is, it works, but > afaict it's massive overkill. > > COOKIE_CMP_RETURN(task_cookie); > COOKIE_CMP_RETURN(group_cookie); > COOKIE_CMP_RETURN(color); > > So if task_cookie matches, we consider group_cookie, if that matches we > consider color. > > Now, afaict that's semantically exactly the same as just using the > narrowest cookie. That is, use the task cookie if there is, and then, > walking the cgroup hierarchy (up) pick the first cgroup cookie. > > (I don't understand the color thing, but lets have that discussion in > that subthread) > > Which means you only need a single active cookie field. > > IOW, you're just making things complicated and expensive. > For the per-task interface, I believe we still want to prevent two tasks that share a task cookie from sharing an overall cookie if they are in two separately tagged groups (Joel please correct me if I'm mistaken there). That's why in Joel's older patch, the overall cookie was a combination of the task and group cookies. My concern about that was the potential cookie collision. I followed up on the 'color' portion in the other thread. Thanks, Josh
[PATCH v2 2/4] misc: rtsx: modify and fix init_hw function
From: Ricky Wu
changed rtsx_pci_disable_aspm() to rtsx_disable_aspm()
do not access ASPM configuration directly
changed pcie_capability_write_word() to _clear_and_set_word()
make sure only change PCI_EXP_LNKCTL bit8
make sure ASPM disable after extra_init_hw()
Signed-off-by: Ricky Wu
---
drivers/misc/cardreader/rtsx_pcr.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/cardreader/rtsx_pcr.c
b/drivers/misc/cardreader/rtsx_pcr.c
index c87f791bdcb5..3612063cab09 100644
--- a/drivers/misc/cardreader/rtsx_pcr.c
+++ b/drivers/misc/cardreader/rtsx_pcr.c
@@ -1289,7 +1289,7 @@ static int rtsx_pci_init_hw(struct rtsx_pcr *pcr)
/* Wait SSC power stable */
udelay(200);
- rtsx_pci_disable_aspm(pcr);
+ rtsx_disable_aspm(pcr);
if (pcr->ops->optimize_phy) {
err = pcr->ops->optimize_phy(pcr);
if (err < 0)
@@ -1363,8 +1363,8 @@ static int rtsx_pci_init_hw(struct rtsx_pcr *pcr)
rtsx_pci_init_ocp(pcr);
/* Enable clk_request_n to enable clock power management */
- pcie_capability_write_word(pdev, PCI_EXP_LNKCTL,
- PCI_EXP_LNKCTL_CLKREQ_EN);
+ pcie_capability_clear_and_set_word(pcr->pci, PCI_EXP_LNKCTL,
+ 0, PCI_EXP_LNKCTL_CLKREQ_EN);
/* Enter L1 when host tx idle */
pci_write_config_byte(pdev, 0x70F, 0x5B);
@@ -1374,6 +1374,8 @@ static int rtsx_pci_init_hw(struct rtsx_pcr *pcr)
return err;
}
+ rtsx_pci_write_register(pcr, ASPM_FORCE_CTL, 0x30, 0x30);
+
/* No CD interrupt if probing driver with card inserted.
* So we need to initialize pcr->card_exist here.
*/
--
2.17.1
[PATCH v2 1/4] misc: rtsx: modify en/disable aspm function
From: Ricky Wu enable/disable device ASPM function: changed write ASPM configuration directly to use write register Signed-off-by: Ricky Wu --- drivers/misc/cardreader/rtsx_pcr.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/misc/cardreader/rtsx_pcr.c b/drivers/misc/cardreader/rtsx_pcr.c index 5d15607027e9..c87f791bdcb5 100644 --- a/drivers/misc/cardreader/rtsx_pcr.c +++ b/drivers/misc/cardreader/rtsx_pcr.c @@ -89,9 +89,15 @@ static void rtsx_comm_set_aspm(struct rtsx_pcr *pcr, bool enable) if (pcr->aspm_enabled == enable) return; - pcie_capability_clear_and_set_word(pcr->pci, PCI_EXP_LNKCTL, - PCI_EXP_LNKCTL_ASPMC, - enable ? pcr->aspm_en : 0); + if (pcr->aspm_en & 0x02) + rtsx_pci_write_register(pcr, ASPM_FORCE_CTL, FORCE_ASPM_CTL0 | + FORCE_ASPM_CTL1, enable ? 0 : FORCE_ASPM_CTL0 | FORCE_ASPM_CTL1); + else + rtsx_pci_write_register(pcr, ASPM_FORCE_CTL, FORCE_ASPM_CTL0 | + FORCE_ASPM_CTL1, FORCE_ASPM_CTL0 | FORCE_ASPM_CTL1); + + if (!enable && (pcr->aspm_en & 0x02)) + mdelay(10); pcr->aspm_enabled = enable; } -- 2.17.1
Re: [PATCH] Revert "i2c: qcom-geni: Disable DMA processing on the Lenovo Yoga C630"
On 11/25/2020 12:27 AM, Bjorn Andersson wrote:
A combination of recent bug fixes by Doug Anderson and the proper
definition of iommu streams means that this hack is no longer needed.
Let's clean up the code by reverting '127068abe85b ("i2c: qcom-geni:
Disable DMA processing on the Lenovo Yoga C630")'.
Signed-off-by: Bjorn Andersson
Reviewed-by: Akash Asthana
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na
Linux Foundation Collaborative Project
Re: [f2fs-dev] [PATCH v2 1/2] f2fs: add compress_mode mount option
On 2020/12/1 12:08, Daeho Jeong wrote:
From: Daeho Jeong
We will add a new "compress_mode" mount option to control file
compression mode. This supports "fs" and "user". In "fs" mode (default),
f2fs does automatic compression on the compression enabled files.
In "user" mode, f2fs disables the automaic compression and gives the
user discretion of choosing the target file and the timing. It means
the user can do manual compression/decompression on the compression
enabled files using ioctls.
Signed-off-by: Daeho Jeong
---
v2: changed mount option name and added more explanation of mount option
---
Documentation/filesystems/f2fs.rst | 35 ++
fs/f2fs/compress.c | 2 +-
fs/f2fs/data.c | 2 +-
fs/f2fs/f2fs.h | 30 +
fs/f2fs/segment.c | 2 +-
fs/f2fs/super.c| 23
6 files changed, 91 insertions(+), 3 deletions(-)
diff --git a/Documentation/filesystems/f2fs.rst
b/Documentation/filesystems/f2fs.rst
index b8ee761c9922..5eb8d63439ec 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -260,6 +260,13 @@ compress_extension=%s Support adding specified
extension, so that f2fs can enab
For other files, we can still enable compression via
ioctl.
Note that, there is one reserved special extension
'*', it
can be set to enable compression for all files.
+compress_mode=%sControl file compression mode. This supports "fs" and
"user"
+modes. In "fs" mode (default), f2fs does automatic
compression
+on the compression enabled files. In "user" mode, f2fs
disables
+the automaic compression and gives the user discretion
of
+choosing the target file and the timing. The user can
do manual
+compression/decompression on the compression enabled
files using
+ioctls.
inlinecryptWhen possible, encrypt/decrypt the contents of
encrypted
files using the blk-crypto framework rather than
filesystem-layer encryption. This allows the use of
@@ -810,6 +817,34 @@ Compress metadata layout::
| data length | data chksum | reserved | compressed data |
+-+-+--++
+Compression mode
+--
+
+f2fs supports "fs" and "user" compression modes with "compression_mode" mount
option.
+With this option, f2fs provides a choice to select the way how to compress the
+compression enabled files (refer to "Compression implementation" section for
how to
+enable compression on a regular inode).
+
+1) compress_mode=fs
+This is the default option. f2fs does automatic compression in the writeback
of the
+compression enabled files.
+
+2) compress_mode=user
+This disables the automaic compression and gives the user discretion of
choosing the
+target file and the timing. The user can do manual compression/decompression
on the
+compression enabled files using F2FS_IOC_DECOMPRESS_FILE and
F2FS_IOC_COMPRESS_FILE
+ioctls like the below.
+
+To decompress a file,
+
+fd = open(filename, O_WRONLY, 0);
+ret = ioctl(fd, F2FS_IOC_DECOMPRESS_FILE);
+
+To compress a file,
+
+fd = open(filename, O_WRONLY, 0);
+ret = ioctl(fd, F2FS_IOC_COMPRESS_FILE);
+
NVMe Zoned Namespace devices
diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
index 3957a84a185e..87090da8693d 100644
--- a/fs/f2fs/compress.c
+++ b/fs/f2fs/compress.c
@@ -926,7 +926,7 @@ int f2fs_is_compressed_cluster(struct inode *inode, pgoff_t
index)
static bool cluster_may_compress(struct compress_ctx *cc)
{
- if (!f2fs_compressed_file(cc->inode))
+ if (!f2fs_need_compress_data(cc->inode))
return false;
if (f2fs_is_atomic_file(cc->inode))
return false;
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index be4da52604ed..42254d3859c7 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -3164,7 +3164,7 @@ static inline bool __should_serialize_io(struct inode
*inode,
if (IS_NOQUOTA(inode))
return false;
- if (f2fs_compressed_file(inode))
+ if (f2fs_need_compress_data(inode))
return true;
if (wbc->sync_mode != WB_SYNC_ALL)
return true;
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index e0826779a101..94d16bde5e24 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -149,6 +149,7 @@ struct f2fs_mount_info {
unsigned char compress_algorithm; /* algorithm type */
unsigned compress_log_size; /* cluster log size */
unsigned char compress_ext_cnt; /* extension count */
+ int compress_mode;
linux-next: no release today
Hi all, There will be no linux-next release today as I have just run out of time to finish it. Normal service will hopefully return tomorrow. -- Cheers, Stephen Rothwell pgpAtDK6RQ21Z.pgp Description: OpenPGP digital signature
[PATCH v4 1/5] perf metric: Restructure struct expr_parse_ctx.
A later change to parsing the ids out (in expr__find_other) will
potentially drop hashmaps and so it is more convenient to move
expr_parse_ctx to have a hashmap pointer rather than a struct value. As
this pointer must be freed, rather than just going out of scope,
add expr__ctx_new and expr__ctx_free to manage expr_parse_ctx memory.
Adjust use of struct expr_parse_ctx accordingly.
Signed-off-by: Ian Rogers
---
tools/perf/tests/expr.c | 81 ++-
tools/perf/tests/pmu-events.c | 37 +---
tools/perf/util/expr.c| 38
tools/perf/util/expr.h| 5 ++-
tools/perf/util/metricgroup.c | 44 ++-
tools/perf/util/stat-shadow.c | 50 +
6 files changed, 151 insertions(+), 104 deletions(-)
diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
index 4d01051951cd..b0a3b5fd0c00 100644
--- a/tools/perf/tests/expr.c
+++ b/tools/perf/tests/expr.c
@@ -22,67 +22,70 @@ int test__expr(struct test *t __maybe_unused, int subtest
__maybe_unused)
const char *p;
double val;
int ret;
- struct expr_parse_ctx ctx;
+ struct expr_parse_ctx *ctx;
- expr__ctx_init();
- expr__add_id_val(, strdup("FOO"), 1);
- expr__add_id_val(, strdup("BAR"), 2);
+ ctx = expr__ctx_new();
+ TEST_ASSERT_VAL("expr__ctx_new", ctx);
+ expr__add_id_val(ctx, strdup("FOO"), 1);
+ expr__add_id_val(ctx, strdup("BAR"), 2);
- ret = test(, "1+1", 2);
- ret |= test(, "FOO+BAR", 3);
- ret |= test(, "(BAR/2)%2", 1);
- ret |= test(, "1 - -4", 5);
- ret |= test(, "(FOO-1)*2 + (BAR/2)%2 - -4", 5);
- ret |= test(, "1-1 | 1", 1);
- ret |= test(, "1-1 & 1", 0);
- ret |= test(, "min(1,2) + 1", 2);
- ret |= test(, "max(1,2) + 1", 3);
- ret |= test(, "1+1 if 3*4 else 0", 2);
- ret |= test(, "1.1 + 2.1", 3.2);
- ret |= test(, ".1 + 2.", 2.1);
- ret |= test(, "d_ratio(1, 2)", 0.5);
- ret |= test(, "d_ratio(2.5, 0)", 0);
- ret |= test(, "1.1 < 2.2", 1);
- ret |= test(, "2.2 > 1.1", 1);
- ret |= test(, "1.1 < 1.1", 0);
- ret |= test(, "2.2 > 2.2", 0);
- ret |= test(, "2.2 < 1.1", 0);
- ret |= test(, "1.1 > 2.2", 0);
+ ret = test(ctx, "1+1", 2);
+ ret |= test(ctx, "FOO+BAR", 3);
+ ret |= test(ctx, "(BAR/2)%2", 1);
+ ret |= test(ctx, "1 - -4", 5);
+ ret |= test(ctx, "(FOO-1)*2 + (BAR/2)%2 - -4", 5);
+ ret |= test(ctx, "1-1 | 1", 1);
+ ret |= test(ctx, "1-1 & 1", 0);
+ ret |= test(ctx, "min(1,2) + 1", 2);
+ ret |= test(ctx, "max(1,2) + 1", 3);
+ ret |= test(ctx, "1+1 if 3*4 else 0", 2);
+ ret |= test(ctx, "1.1 + 2.1", 3.2);
+ ret |= test(ctx, ".1 + 2.", 2.1);
+ ret |= test(ctx, "d_ratio(1, 2)", 0.5);
+ ret |= test(ctx, "d_ratio(2.5, 0)", 0);
+ ret |= test(ctx, "1.1 < 2.2", 1);
+ ret |= test(ctx, "2.2 > 1.1", 1);
+ ret |= test(ctx, "1.1 < 1.1", 0);
+ ret |= test(ctx, "2.2 > 2.2", 0);
+ ret |= test(ctx, "2.2 < 1.1", 0);
+ ret |= test(ctx, "1.1 > 2.2", 0);
- if (ret)
+ if (ret) {
+ expr__ctx_free(ctx);
return ret;
+ }
p = "FOO/0";
- ret = expr__parse(, , p, 1);
+ ret = expr__parse(, ctx, p, 1);
TEST_ASSERT_VAL("division by zero", ret == -1);
p = "BAR/";
- ret = expr__parse(, , p, 1);
+ ret = expr__parse(, ctx, p, 1);
TEST_ASSERT_VAL("missing operand", ret == -1);
- expr__ctx_clear();
+ expr__ctx_clear(ctx);
TEST_ASSERT_VAL("find other",
expr__find_other("FOO + BAR + BAZ + BOZO", "FOO",
-, 1) == 0);
- TEST_ASSERT_VAL("find other", hashmap__size() == 3);
- TEST_ASSERT_VAL("find other", hashmap__find(, "BAR",
+ctx, 1) == 0);
+ TEST_ASSERT_VAL("find other", hashmap__size(ctx->ids) == 3);
+ TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BAR",
(void **)_ptr));
- TEST_ASSERT_VAL("find other", hashmap__find(, "BAZ",
+ TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BAZ",
(void **)_ptr));
- TEST_ASSERT_VAL("find other", hashmap__find(, "BOZO",
+ TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BOZO",
(void **)_ptr));
- expr__ctx_clear();
+ expr__ctx_clear(ctx);
TEST_ASSERT_VAL("find other",
expr__find_other("EVENT1\\,param\\=?@ +
EVENT2\\,param\\=?@",
-NULL, , 3) == 0);
- TEST_ASSERT_VAL("find other", hashmap__size() == 2);
- TEST_ASSERT_VAL("find other", hashmap__find(, "EVENT1,param=3/",
+
[PATCH v4 5/5] perf metric: Don't compute unused events.
For a metric like:
EVENT1 if #smt_on else EVENT2
currently EVENT1 and EVENT2 will be measured and then when the metric is
reported EVENT1 or EVENT2 will be printed depending on the value from
smt_on() during the expr parsing. Computing both events is unnecessary and
can lead to multiplexing as discussed in this thread:
https://lore.kernel.org/lkml/20201110100346.2527031-1-irog...@google.com/
This change modifies the expression parsing code by:
- getting rid of the "other" parsing and introducing a boolean argument
to say whether ids should be computed or not.
- expressions are changed so that a pair of value and ids are returned.
- when computing the metric value the ids are unused.
- when computing the ids, constant values and smt_on are assigned to
the value.
- If the value is from an event ID then the event is added to the ids
hashmap and the value set to bottom (encoded as NAN).
- Typically operators union IDs for their inputs and set the value to
bottom, however, if the inputs are constant then these are computed and
propagated as the value.
- If the input is constant to certain operators like:
IDS1 if CONST else IDS2
then the result will be either IDS1 or IDS2 depending on CONST (which
may be evaluated from an entire expression), and so IDS1 or IDS2 may
be discarded avoiding events from being programmed.
- The ids at the end of parsing are added to the context.
Signed-off-by: Ian Rogers
---
tools/perf/tests/expr.c | 17 ++
tools/perf/util/expr.c | 9 +-
tools/perf/util/expr.h | 1 -
tools/perf/util/expr.l | 9 -
tools/perf/util/expr.y | 415
5 files changed, 354 insertions(+), 97 deletions(-)
diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
index 1c881bea7fca..5cab5960b257 100644
--- a/tools/perf/tests/expr.c
+++ b/tools/perf/tests/expr.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#include "util/debug.h"
#include "util/expr.h"
+#include "util/smt.h"
#include "tests.h"
#include
#include
@@ -132,6 +133,22 @@ int test__expr(struct test *t __maybe_unused, int subtest
__maybe_unused)
TEST_ASSERT_VAL("find ids", hashmap__find(ctx->ids, "EVENT2,param=3/",
(void **)_ptr));
+ /* Only EVENT1 or EVENT2 need be measured depending on the value of
smt_on. */
+ expr__ctx_clear(ctx);
+ TEST_ASSERT_VAL("find ids",
+ expr__find_ids("EVENT1 if #smt_on else EVENT2",
+ NULL, ctx, 0) == 0);
+ TEST_ASSERT_VAL("find ids", hashmap__size(ctx->ids) == 1);
+ TEST_ASSERT_VAL("find ids", hashmap__find(ctx->ids,
+ smt_on() ? "EVENT1" :
"EVENT2",
+ (void **)_ptr));
+
+ /* The expression is a constant 1.0 without needing to evaluate EVENT1.
*/
+ expr__ctx_clear(ctx);
+ TEST_ASSERT_VAL("find ids",
+ expr__find_ids("1.0 if EVENT1 > 100.0 else 1.0",
+ NULL, ctx, 0) == 0);
+ TEST_ASSERT_VAL("find ids", hashmap__size(ctx->ids) == 0);
expr__ctx_free(ctx);
return 0;
diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
index 1adb6cd202e0..28aaa50c6c68 100644
--- a/tools/perf/util/expr.c
+++ b/tools/perf/util/expr.c
@@ -329,10 +329,9 @@ void expr__ctx_free(struct expr_parse_ctx *ctx)
static int
__expr__parse(double *val, struct expr_parse_ctx *ctx, const char *expr,
- int start, int runtime)
+ bool compute_ids, int runtime)
{
struct expr_scanner_ctx scanner_ctx = {
- .start_token = start,
.runtime = runtime,
};
YY_BUFFER_STATE buffer;
@@ -352,7 +351,7 @@ __expr__parse(double *val, struct expr_parse_ctx *ctx,
const char *expr,
expr_set_debug(1, scanner);
#endif
- ret = expr_parse(val, ctx, scanner);
+ ret = expr_parse(val, ctx, compute_ids, scanner);
expr__flush_buffer(buffer, scanner);
expr__delete_buffer(buffer, scanner);
@@ -363,13 +362,13 @@ __expr__parse(double *val, struct expr_parse_ctx *ctx,
const char *expr,
int expr__parse(double *final_val, struct expr_parse_ctx *ctx,
const char *expr, int runtime)
{
- return __expr__parse(final_val, ctx, expr, EXPR_PARSE, runtime) ? -1 :
0;
+ return __expr__parse(final_val, ctx, expr, /*compute_ids=*/false,
runtime) ? -1 : 0;
}
int expr__find_ids(const char *expr, const char *one,
struct expr_parse_ctx *ctx, int runtime)
{
- int ret = __expr__parse(NULL, ctx, expr, EXPR_OTHER, runtime);
+ int ret = __expr__parse(NULL, ctx, expr, /*compute_ids=*/true, runtime);
if (one)
expr__del_id(ctx, one);
diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
index 62d3ae5ddfba..cefeb2c8d85e 100644
--- a/tools/perf/util/expr.h
Re: [PATCH v2 bpf-next 00/13] Atomics for eBPF
Andrii Nakryiko wrote: > On Tue, Dec 1, 2020 at 9:53 PM John Fastabend > wrote: > > > > Yonghong Song wrote: > > > > > > > > > > [...] > > > > > > Great, this means that all existing valid uses of > > > > __sync_fetch_and_add() will generate BPF_XADD instructions and will > > > > work on old kernels, right? > > > > > > That is correct. > > > > > > > > > > > If that's the case, do we still need cpu=v4? The new instructions are > > > > *only* going to be generated if the user uses previously unsupported > > > > __sync_fetch_xxx() intrinsics. So, in effect, the user consciously > > > > opts into using new BPF instructions. cpu=v4 seems like an unnecessary > > > > tautology then? > > > > > > This is a very good question. Essentially this boils to when users can > > > use the new functionality including meaningful return value of > > > __sync_fetch_and_add(). > > >(1). user can write a small bpf program to test the feature. If user > > > gets a failed compilation (fatal error), it won't be supported. > > > Otherwise, it is supported. > > >(2). compiler provides some way to tell user it is safe to use, e.g., > > > -mcpu=v4, or some clang macro suggested by Brendan earlier. > > > > > > I guess since kernel already did a lot of feature discovery. Option (1) > > > is probably fine. > > > > For option (2) we can use BTF with kernel version check. If kernel is > > greater than kernel this lands in we use the the new instructions if > > not we use a slower locked version. That should work for all cases > > unless someone backports patches into an older case. > > Two different things: Clang support detection and kernel support > detection. You are talking about kernel detection, I and Yonghong were > talking about Clang detection and explicit cpu=v4 opt-in. > Ah right, catching up on email and reading the thread backwords I lost the context thanks! So, I live in a dev world where I control the build infrastructure so always know clang/llvm versions and features. What I don't know as well is where the program I just built might be run. So its a bit of an odd question from my perspective to ask if my clang supports feature X. If it doesn't support feature X and I want it we upgrade clang so that it does support it. I don't think we would ever write a program to test the assertion. Anyways thanks. > For kernel detection, if there is an enum value or type that gets > added along the feature, then with CO-RE built-ins it's easy to detect > and kernel dead code elimination will make sure that unsupported > instructions won't trip up the BPF verifier. Still need Clang support > to compile the program in the first place, though. +1 > > If there is no such BTF-based way to check, it is still possible to > try to load a trivial BPF program with __sync_fech_and_xxx() to do > feature detection and then use .rodata to turn off code paths relying > on a new instruction set. Right. > > > > > At least thats what I'll probably end up wrapping in a helper function.
[PATCH v4 3/5] perf metric: Rename expr__find_other.
A later change will remove the notion of other, rename the function to
expr__find_ids as this is what it populates.
Signed-off-by: Ian Rogers
---
tools/perf/tests/expr.c | 26 +-
tools/perf/tests/pmu-events.c | 9 -
tools/perf/util/expr.c| 4 ++--
tools/perf/util/expr.h| 2 +-
tools/perf/util/metricgroup.c | 2 +-
tools/perf/util/stat-shadow.c | 6 +++---
6 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
index b0a3b5fd0c00..7ccb97c73347 100644
--- a/tools/perf/tests/expr.c
+++ b/tools/perf/tests/expr.c
@@ -64,25 +64,25 @@ int test__expr(struct test *t __maybe_unused, int subtest
__maybe_unused)
TEST_ASSERT_VAL("missing operand", ret == -1);
expr__ctx_clear(ctx);
- TEST_ASSERT_VAL("find other",
- expr__find_other("FOO + BAR + BAZ + BOZO", "FOO",
-ctx, 1) == 0);
- TEST_ASSERT_VAL("find other", hashmap__size(ctx->ids) == 3);
- TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BAR",
+ TEST_ASSERT_VAL("find ids",
+ expr__find_ids("FOO + BAR + BAZ + BOZO", "FOO",
+ ctx, 1) == 0);
+ TEST_ASSERT_VAL("find ids", hashmap__size(ctx->ids) == 3);
+ TEST_ASSERT_VAL("find ids", hashmap__find(ctx->ids, "BAR",
(void **)_ptr));
- TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BAZ",
+ TEST_ASSERT_VAL("find ids", hashmap__find(ctx->ids, "BAZ",
(void **)_ptr));
- TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "BOZO",
+ TEST_ASSERT_VAL("find ids", hashmap__find(ctx->ids, "BOZO",
(void **)_ptr));
expr__ctx_clear(ctx);
- TEST_ASSERT_VAL("find other",
- expr__find_other("EVENT1\\,param\\=?@ +
EVENT2\\,param\\=?@",
-NULL, ctx, 3) == 0);
- TEST_ASSERT_VAL("find other", hashmap__size(ctx->ids) == 2);
- TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "EVENT1,param=3/",
+ TEST_ASSERT_VAL("find ids",
+ expr__find_ids("EVENT1\\,param\\=?@ +
EVENT2\\,param\\=?@",
+ NULL, ctx, 3) == 0);
+ TEST_ASSERT_VAL("find ids", hashmap__size(ctx->ids) == 2);
+ TEST_ASSERT_VAL("find ids", hashmap__find(ctx->ids, "EVENT1,param=3/",
(void **)_ptr));
- TEST_ASSERT_VAL("find other", hashmap__find(ctx->ids, "EVENT2,param=3/",
+ TEST_ASSERT_VAL("find ids", hashmap__find(ctx->ids, "EVENT2,param=3/",
(void **)_ptr));
expr__ctx_free(ctx);
diff --git a/tools/perf/tests/pmu-events.c b/tools/perf/tests/pmu-events.c
index 294daf568bb6..3ac70fa31379 100644
--- a/tools/perf/tests/pmu-events.c
+++ b/tools/perf/tests/pmu-events.c
@@ -502,9 +502,8 @@ static int test_parsing(void)
if (!pe->metric_expr)
continue;
expr__ctx_clear(ctx);
- if (expr__find_other(pe->metric_expr, NULL, ctx, 0)
- < 0) {
- expr_failure("Parse other failed", map, pe);
+ if (expr__find_ids(pe->metric_expr, NULL, ctx, 0) < 0) {
+ expr_failure("Parse find ids failed", map, pe);
ret++;
continue;
}
@@ -559,8 +558,8 @@ static int metric_parse_fake(const char *str)
pr_debug("parsing '%s'\n", str);
ctx = expr__ctx_new();
- if (expr__find_other(str, NULL, ctx, 0) < 0) {
- pr_err("expr__find_other failed\n");
+ if (expr__find_ids(str, NULL, ctx, 0) < 0) {
+ pr_err("expr__find_ids failed\n");
return -1;
}
diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
index e0623d38e6ee..a248d14882cc 100644
--- a/tools/perf/util/expr.c
+++ b/tools/perf/util/expr.c
@@ -287,8 +287,8 @@ int expr__parse(double *final_val, struct expr_parse_ctx
*ctx,
return __expr__parse(final_val, ctx, expr, EXPR_PARSE, runtime) ? -1 :
0;
}
-int expr__find_other(const char *expr, const char *one,
-struct expr_parse_ctx *ctx, int runtime)
+int expr__find_ids(const char *expr, const char *one,
+ struct expr_parse_ctx *ctx, int runtime)
{
int ret = __expr__parse(NULL, ctx, expr, EXPR_OTHER, runtime);
diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
index 00b941cfe6a6..955d5adb7ca4 100644
--- a/tools/perf/util/expr.h
+++ b/tools/perf/util/expr.h
@@ -43,7 +43,7 @@ int expr__resolve_id(struct
[PATCH v4 4/5] perf metric: Add utilities to work on ids map.
Add utilities to new/free an ids hashmap, as well as to union. Add
testing of the union. Unioning hashmaps will be used when parsing the
metric, if a value is known then the hashmap is unnecessary, otherwise
we need to union together all the event ids to compute their values for
reporting.
Signed-off-by: Ian Rogers
---
tools/perf/tests/expr.c | 47 ++
tools/perf/util/expr.c | 87 +++--
tools/perf/util/expr.h | 9 +
3 files changed, 139 insertions(+), 4 deletions(-)
diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
index 7ccb97c73347..1c881bea7fca 100644
--- a/tools/perf/tests/expr.c
+++ b/tools/perf/tests/expr.c
@@ -6,6 +6,51 @@
#include
#include
+static int test_ids_union(void)
+{
+ struct hashmap *ids1, *ids2;
+
+ /* Empty union. */
+ ids1 = ids__new();
+ TEST_ASSERT_VAL("ids__new", ids1);
+ ids2 = ids__new();
+ TEST_ASSERT_VAL("ids__new", ids2);
+
+ ids1 = ids__union(ids1, ids2);
+ TEST_ASSERT_EQUAL("union", (int)hashmap__size(ids1), 0);
+
+ /* Union {foo, bar} against {}. */
+ ids2 = ids__new();
+ TEST_ASSERT_VAL("ids__new", ids2);
+
+ TEST_ASSERT_EQUAL("ids__insert", ids__insert(ids1, strdup("foo"),
NULL), 0);
+ TEST_ASSERT_EQUAL("ids__insert", ids__insert(ids1, strdup("bar"),
NULL), 0);
+
+ ids1 = ids__union(ids1, ids2);
+ TEST_ASSERT_EQUAL("union", (int)hashmap__size(ids1), 2);
+
+ /* Union {foo, bar} against {foo}. */
+ ids2 = ids__new();
+ TEST_ASSERT_VAL("ids__new", ids2);
+ TEST_ASSERT_EQUAL("ids__insert", ids__insert(ids2, strdup("foo"),
NULL), 0);
+
+ ids1 = ids__union(ids1, ids2);
+ TEST_ASSERT_EQUAL("union", (int)hashmap__size(ids1), 2);
+
+ /* Union {foo, bar} against {bar,baz}. */
+ ids2 = ids__new();
+ TEST_ASSERT_VAL("ids__new", ids2);
+ TEST_ASSERT_EQUAL("ids__insert", ids__insert(ids2, strdup("bar"),
NULL), 0);
+ TEST_ASSERT_EQUAL("ids__insert", ids__insert(ids2, strdup("baz"),
NULL), 0);
+
+ ids1 = ids__union(ids1, ids2);
+ TEST_ASSERT_EQUAL("union", (int)hashmap__size(ids1), 3);
+
+ ids__free(ids1);
+
+ return 0;
+}
+
static int test(struct expr_parse_ctx *ctx, const char *e, double val2)
{
double val;
@@ -24,6 +69,8 @@ int test__expr(struct test *t __maybe_unused, int subtest
__maybe_unused)
int ret;
struct expr_parse_ctx *ctx;
+ TEST_ASSERT_EQUAL("ids_union", test_ids_union(), 0);
+
ctx = expr__ctx_new();
TEST_ASSERT_VAL("expr__ctx_new", ctx);
expr__add_id_val(ctx, strdup("FOO"), 1);
diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
index a248d14882cc..1adb6cd202e0 100644
--- a/tools/perf/util/expr.c
+++ b/tools/perf/util/expr.c
@@ -59,8 +59,48 @@ static bool key_equal(const void *key1, const void *key2,
return !strcmp((const char *)key1, (const char *)key2);
}
-/* Caller must make sure id is allocated */
-int expr__add_id(struct expr_parse_ctx *ctx, const char *id)
+struct hashmap *ids__new(void)
+{
+ return hashmap__new(key_hash, key_equal, NULL);
+}
+
+void ids__free(struct hashmap *ids)
+{
+ struct hashmap_entry *cur;
+ size_t bkt;
+
+ if (ids == NULL)
+ return;
+
+#ifdef PARSER_DEBUG
+ fprintf(stderr, "freeing ids: ");
+ ids__print(ids);
+ fprintf(stderr, "\n");
+#endif
+
+ hashmap__for_each_entry(ids, cur, bkt) {
+ free((char *)cur->key);
+ free(cur->value);
+ }
+
+ hashmap__free(ids);
+}
+
+void ids__print(struct hashmap *ids)
+{
+ size_t bkt;
+ struct hashmap_entry *cur;
+
+ if (!ids)
+ return;
+
+ hashmap__for_each_entry(ids, cur, bkt) {
+ fprintf(stderr, "key:%s, ", (const char *)cur->key);
+ }
+}
+
+int ids__insert(struct hashmap *ids, const char *id,
+ struct expr_id *parent)
{
struct expr_id_data *data_ptr = NULL, *old_data = NULL;
char *old_key = NULL;
@@ -70,10 +110,10 @@ int expr__add_id(struct expr_parse_ctx *ctx, const char
*id)
if (!data_ptr)
return -ENOMEM;
- data_ptr->parent = ctx->parent;
+ data_ptr->parent = parent;
data_ptr->kind = EXPR_ID_DATA__PARENT;
- ret = hashmap__set(ctx->ids, id, data_ptr,
+ ret = hashmap__set(ids, id, data_ptr,
(const void **)_key, (void **)_data);
if (ret)
free(data_ptr);
@@ -82,6 +122,45 @@ int expr__add_id(struct expr_parse_ctx *ctx, const char *id)
return ret;
}
+struct hashmap *ids__union(struct hashmap *ids1, struct hashmap *ids2)
+{
+ size_t bkt;
+ struct hashmap_entry *cur;
+ int ret;
+ struct expr_id_data *old_data = NULL;
+ char *old_key = NULL;
+
+ if (!ids1)
+ return ids2;
+
+ if (!ids2)
+ return
[PATCH v4 2/5] perf metric: Use NAN for missing event IDs.
If during computing a metric an event (id) is missing the parsing
aborts. A later patch will make it so that events that aren't used in
the output are deliberately omitted, in which case we don't want the
abort. Modify the missing ID case to report NAN for these cases.
Signed-off-by: Ian Rogers
---
tools/perf/util/expr.y | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/expr.y b/tools/perf/util/expr.y
index b2ada8f8309a..41c9cd4efadd 100644
--- a/tools/perf/util/expr.y
+++ b/tools/perf/util/expr.y
@@ -1,6 +1,7 @@
/* Simple expression parser */
%{
#define YYDEBUG 1
+#include
#include
#include "util.h"
#include "util/debug.h"
@@ -88,12 +89,10 @@ expr: NUMBER
| ID{
struct expr_id_data *data;
- if (expr__resolve_id(ctx, $1, )) {
- free($1);
- YYABORT;
- }
+ $$ = NAN;
+ if (expr__resolve_id(ctx, $1, ) ==
0)
+ $$ = expr_id_data__value(data);
- $$ = expr_id_data__value(data);
free($1);
}
| expr '|' expr { $$ = (long)$1 | (long)$3; }
--
2.29.2.454.gaff20da3a2-goog
[PATCH v4 0/5] Don't compute events that won't be used in a metric.
For a metric like: EVENT1 if #smt_on else EVENT2 currently EVENT1 and EVENT2 will be measured and then when the metric is reported EVENT1 or EVENT2 will be printed depending on the value from smt_on() during the expr parsing. Computing both events is unnecessary and can lead to multiplexing as discussed in this thread: https://lore.kernel.org/lkml/20201110100346.2527031-1-irog...@google.com/ This change modifies expression parsing so that constants are considered when building the set of ids (events) and only events not contributing to a constant value are measured. v4. reduces references to BOTTOM/NAN in patch 5/5 by using utility functions. It improves comments and fixes an unnecessary union in a peephole optimization. v3. fixes an assignment in patch 2/5. In patch 5/5 additional comments are added and useless frees are replaced by asserts. A new peephole optimization is added for the case CONST IF expr ELSE CONST, where the the constants are identical, as we don't need to evaluate the IF condition. v2. is a rebase. Ian Rogers (5): perf metric: Restructure struct expr_parse_ctx. perf metric: Use NAN for missing event IDs. perf metric: Rename expr__find_other. perf metric: Add utilities to work on ids map. perf metric: Don't compute unused events. tools/perf/tests/expr.c | 159 + tools/perf/tests/pmu-events.c | 42 ++-- tools/perf/util/expr.c| 136 +-- tools/perf/util/expr.h| 17 +- tools/perf/util/expr.l| 9 - tools/perf/util/expr.y| 418 +++--- tools/perf/util/metricgroup.c | 44 ++-- tools/perf/util/stat-shadow.c | 54 +++-- 8 files changed, 658 insertions(+), 221 deletions(-) -- 2.29.2.454.gaff20da3a2-goog
/proc/net/sctp/snmp, setns, proc: revalidate misc dentries
Hello,
Bisected problems with setns() and /proc/net/sctp/snmp to this:
commit 1da4d377f943fe4194ffb9fb9c26cc58fad4dd24
Author: Alexey Dobriyan
Date: Fri Apr 13 15:35:42 2018 -0700
proc: revalidate misc dentries
Reproduces for example with Fedora 5.9.10-100.fc32.x86_64, so 1fde6f21d90f
("proc: fix /proc/net/* after setns(2)") does not seem to cover
/proc/net/sctp/snmp
Reproducer attached, that does open+read+close of /proc/net/sctp/snmp before
and after setns() syscall. The second open+read+close of /proc/net/sctp/snmp
incorrectly produces results for the default namespace, not the target
namespace.
Example, create netns and do some sctp:
# ./iperf-netns
+ modprobe sctp
+ ip netns add test
+ ip netns exec test ip link set lo up
+ ip netns exec test iperf3 -s -1
---
Server listening on 5201
---
+ ip netns exec test iperf3 -c 127.0.0.1 --sctp --bitrate 50M --time 4
Connecting to host 127.0.0.1, port 5201
Accepted connection from 127.0.0.1, port 50696
[ 5] local 127.0.0.1 port 54735 connected to 127.0.0.1 port 5201
[ 5] local 127.0.0.1 port 5201 connected to 127.0.0.1 port 54735
[ ID] Interval Transfer Bitrate
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 6.00 MBytes 50.3 Mbits/sec
[ 5] 0.00-1.00 sec 6.00 MBytes 50.3 Mbits/sec
[ 5] 1.00-2.00 sec 5.94 MBytes 49.8 Mbits/sec
[ 5] 1.00-2.00 sec 5.94 MBytes 49.8 Mbits/sec
[ 5] 2.00-3.00 sec 6.00 MBytes 50.3 Mbits/sec
[ 5] 2.00-3.00 sec 6.00 MBytes 50.3 Mbits/sec
[ 5] 3.00-4.00 sec 5.94 MBytes 49.8 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-4.00 sec 23.9 MBytes 50.1
Mbits/sec receiver
[ 5] 3.00-4.00 sec 5.94 MBytes 49.8 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-4.00 sec 23.9 MBytes 50.1 Mbits/sec
[ 5] 0.00-4.00 sec 23.9 MBytes 50.1
iperf Done.
+ cat /proc/net/sctp/snmp
SctpCurrEstab 0
SctpActiveEstabs0
SctpPassiveEstabs 0
SctpAborteds0
SctpShutdowns 0
SctpOutOfBlues 0
SctpChecksumErrors 0
[...]
+ ip netns exec test cat /proc/net/sctp/snmp
SctpCurrEstab 0
SctpActiveEstabs2
SctpPassiveEstabs 2
SctpAborteds0
SctpShutdowns 4
SctpOutOfBlues 0
SctpChecksumErrors 0
SctpOutCtrlChunks 1544
SctpOutOrderChunks 1530
[...]
+ wait
But now we see all zeroes in /proc/net/sctp/snmp with the reproducer:
$ gcc repro.c -o repro
# ./repro
/proc/net/sctp/snmp [pid: 175998]
SctpCurrEstab 0
SctpActiveEstabs0
SctpPassiveEstabs 0
SctpAborteds0
SctpShutdowns 0
[...]
setns(/run/netns/test) ...
/proc/net/sctp/snmp [pid: 175998]
SctpCurrEstab 0
SctpActiveEstabs0
SctpPassiveEstabs 0
SctpAborteds0
SctpShutdowns 0
SctpOutOfBlues 0
[...]
-Tommi
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
void slurp(const char *fn)
{
char buf[8192];
ssize_t r;
int fd;
printf("%s [pid: %d]\n", fn, getpid()); fflush(stdout);
fd = open(fn, O_RDONLY);
if (fd < 0) { perror("open"); exit(1); }
r = read(fd, buf, sizeof(buf)-1);
if (r < 0) { perror("read"); exit(1); }
buf[r] = 0;
puts(buf); fflush(stdout);
if (close(fd) < 0) { perror("close"); exit(1); }
}
void newnet(const char *ns)
{
int fd;
fd = open(ns, O_RDONLY);
if (fd < 0) { perror("open"); exit(1); }
if (setns(fd, CLONE_NEWNET) < 0) { perror("setns"); exit(1); }
if (close(fd) < 0) { perror("close"); exit(1); }
}
int main(int argc, char **argv)
{
const char *ns = "/run/netns/test";
const char *fn = "/proc/net/sctp/snmp";
int d = 1;
// Optional args: /run/netns/... /proc/net/... n
if (argc >= 2) ns = argv[1];
if (argc >= 3) fn = argv[2];
if (argc >= 4 && argv[3][0] == 'n') d = 0;
if (d) slurp(fn);
printf("setns(%s) ...\n", ns); fflush(stdout);
newnet(ns);
slurp(fn);
}
iperf-netns
Description: iperf-netns
Re: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module
On Tue, Dec 01, 2020 at 02:34:52PM -0800, mgr...@linux.intel.com wrote: > From: Daniele Alessandrelli > > On the Intel Movidius SoC code named Keem Bay, communication between the > Computing Sub-System (CSS), i.e., the CPU, and the Multimedia Sub-System > (MSS), i.e., the VPU is enabled by the Keem Bay Inter-Processor > Communication (IPC) mechanism. > > Add the driver for using Keem Bay IPC from within the Linux Kernel. > > Keem Bay IPC uses the following terminology: > > - Node:A processing entity that can use the IPC to communicate; > currently, we just have two nodes, CPU (CSS) and VPU (MSS). > > - Link:Two nodes that can communicate over IPC form an IPC link > (currently, we just have one link, the one between the CPU > and VPU). > > - Channel: An IPC link can provide multiple IPC channels. IPC channels > allow communication multiplexing, i.e., the same IPC link can > be used by different applications for different > communications. Each channel is identified by a channel ID, > which must be unique within a single IPC link. Channels are > divided in two categories, High-Speed (HS) channels and > General-Purpose (GP) channels. HS channels have higher > priority over GP channels. > > Keem Bay IPC mechanism is based on shared memory and hardware FIFOs. > Both the CPU and the VPU have their own hardware FIFO. When the CPU > wants to send an IPC message to the VPU, it writes to the VPU FIFO (MSS > FIFO); similarly, when MSS wants to send an IPC message to the CPU, it > writes to the CPU FIFO (CSS FIFO). > > A FIFO entry is simply a pointer to an IPC buffer (aka IPC header) > stored in a portion of memory shared between the CPU and the VPU. > Specifically, the FIFO entry contains the (VPU) physical address of the > IPC buffer being transferred. > > In turn, the IPC buffer contains the (VPU) physical address of the > payload (which must be located in shared memory too) as well as other > information (payload size, IPC channel ID, etc.). > > Each IPC node instantiates a pool of IPC buffers from its own IPC buffer > memory region. When instantiated, IPC buffers are marked as free. When > the node needs to send an IPC message, it gets the first free buffer it > finds (from its own pool), marks it as allocated (used), and puts its > physical address into the IPC FIFO of the destination node. The > destination node (which is notified by an interrupt when there are > entries pending in its FIFO) extract the physical address from the FIFO > and process the IPC buffer, marking it as free once done (so that the > sender can reuse the buffer). Any reason you can't use the dmabuf interface for these memory buffers you are creating and having to manage "by hand"? I thought that was what the kernel was wanting to unify on such that individual drivers/subsystems didn't have to do this on their own. thanks, greg k-h
Re: [PATCH -tip 26/32] sched: Add a second-level tag for nested CGroup usecase
Hey Peter,
On Wed, Nov 25, 2020 at 5:43 AM Peter Zijlstra wrote:
>
> Why can't the above work by setting 'tag' (that's a terrible name, why
> does that still live) in CDE? Have the most specific tag live. Same with
> that thread stuff.
The motivation is to allow an unprivileged user the ability to
configure the trust hierarchy in a way that otherwise wouldn't be
possible for a given cgroup hierarchy. For example given a cookie'd
hierarchy such as:
A
/ | | \
B C D E
the user might only want subsets of {B, C, D, E} to share. For
instance, the user might only want {B,C} and {D, E} to share. One way
to solve this would be to allow the user to write the group cookie
directly. However, this interface would need to be restricted to
privileged users, since otherwise the cookie could be configured to
share with any arbitrary cgroup. The purpose of the 'color' field is
to expose a portion of the cookie that can be modified by a
non-privileged user in order to achieve this sharing goal.
If this doesn't seem like a useful case, I'm happy to drop this patch
from the series to unblock it.
> All this API stuff here is a complete and utter trainwreck. Please just
> delete the patches and start over. Hint: if you use stop_machine(),
> you're doing it wrong.
Yes, agree on stop_machine(); we'll pull that out of the underlying
interface patch.
Thanks,
Josh
Re: [PATCH 4.4 00/24] 4.4.247-rc1 review
On Tue, 1 Dec 2020 at 14:24, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.247 release. > There are 24 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, 03 Dec 2020 08:46:29 +. > 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/v4.x/stable-review/patch-4.4.247-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-4.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: 4.4.247-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 412881df37c2300a95caf9e61b42c25814c64af9 git describe: v4.4.246-25-g412881df37c2 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.4.y/build/v4.4.246-25-g412881df37c2 No regressions (compared to build v4.4.246) No fixes (compared to build v4.4.246) Ran 12293 total tests in the following environments and test suites. Environments -- - arm - arm64 - i386 - juno-r2 - arm64 - mips - qemu-arm64-kasan - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - sparc - x15 - arm - x86_64 Test Suites --- * build * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-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-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-controllers-tests * ltp-tracing-tests * libhugetlbfs * v4l2-compliance * install-android-platform-tools-r2600 * network-basic-tests * perf Summary kernel: 4.4.247-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.247-rc1-hikey-20201201-867 git commit: 56c68faa4c221dab59e36da4f9fc198e41a73808 git describe: 4.4.247-rc1-hikey-20201201-867 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.247-rc1-hikey-20201201-867 No regressions (compared to build 4.4.246-rc1-hikey-20201123-865) No fixes (compared to build 4.4.246-rc1-hikey-20201123-865) Ran 1758 total tests in the following environments and test suites. Environments -- - hi6220-hikey - arm64 Test Suites --- * build * install-android-platform-tools-r2600 * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-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-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * spectre-meltdown-checker-test * v4l2-compliance -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 09/22] misc: xlink-pcie: lh: Add core communication logic
On Tue, Dec 01, 2020 at 02:34:58PM -0800, mgr...@linux.intel.com wrote: > From: Srikanth Thokala > > Add logic to establish communication with the remote host which is through > ring buffer management and MSI/Doorbell interrupts > > Reviewed-by: Mark Gross > Signed-off-by: Srikanth Thokala > --- > drivers/misc/xlink-pcie/local_host/Makefile | 2 + > drivers/misc/xlink-pcie/local_host/core.c | 894 > drivers/misc/xlink-pcie/local_host/core.h | 247 ++ > drivers/misc/xlink-pcie/local_host/epf.c| 116 ++- > drivers/misc/xlink-pcie/local_host/epf.h| 26 + > drivers/misc/xlink-pcie/local_host/util.c | 375 > drivers/misc/xlink-pcie/local_host/util.h | 70 ++ > drivers/misc/xlink-pcie/local_host/xpcie.h | 65 ++ > include/linux/xlink_drv_inf.h | 60 ++ > 9 files changed, 1847 insertions(+), 8 deletions(-) > create mode 100644 drivers/misc/xlink-pcie/local_host/core.c > create mode 100644 drivers/misc/xlink-pcie/local_host/core.h > create mode 100644 drivers/misc/xlink-pcie/local_host/util.c > create mode 100644 drivers/misc/xlink-pcie/local_host/util.h > create mode 100644 include/linux/xlink_drv_inf.h > > diff --git a/drivers/misc/xlink-pcie/local_host/Makefile > b/drivers/misc/xlink-pcie/local_host/Makefile > index 54fc118e2dd1..28761751d43b 100644 > --- a/drivers/misc/xlink-pcie/local_host/Makefile > +++ b/drivers/misc/xlink-pcie/local_host/Makefile > @@ -1,3 +1,5 @@ > obj-$(CONFIG_XLINK_PCIE_LH_DRIVER) += mxlk_ep.o > mxlk_ep-objs := epf.o > mxlk_ep-objs += dma.o > +mxlk_ep-objs += core.o > +mxlk_ep-objs += util.o > diff --git a/drivers/misc/xlink-pcie/local_host/core.c > b/drivers/misc/xlink-pcie/local_host/core.c > new file mode 100644 > index ..aecaaa783153 > --- /dev/null > +++ b/drivers/misc/xlink-pcie/local_host/core.c > @@ -0,0 +1,894 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * > + * Intel Keem Bay XLink PCIe Driver > + * > + * Copyright (C) 2020 Intel Corporation > + * > + > / > + > +#include > + > +#include "epf.h" > +#include "core.h" > +#include "util.h" > + > +static struct xpcie *global_xpcie; > + > +static int rx_pool_size = SZ_32M; > +module_param(rx_pool_size, int, 0664); > +MODULE_PARM_DESC(rx_pool_size, "receiving pool size (default 32 MiB)"); > + > +static int tx_pool_size = SZ_32M; > +module_param(tx_pool_size, int, 0664); > +MODULE_PARM_DESC(tx_pool_size, "transmitting pool size (default 32 MiB)"); > + > +static int fragment_size = XPCIE_FRAGMENT_SIZE; > +module_param(fragment_size, int, 0664); > +MODULE_PARM_DESC(fragment_size, "transfer descriptor size (default 128 > KiB)"); > + > +static bool tx_pool_coherent = true; > +module_param(tx_pool_coherent, bool, 0664); > +MODULE_PARM_DESC(tx_pool_coherent, > + "transmitting pool using coherent memory (default true)"); > + > +static bool rx_pool_coherent; > +module_param(rx_pool_coherent, bool, 0664); > +MODULE_PARM_DESC(rx_pool_coherent, > + "receiving pool using coherent memory (default false)"); This isn't the 1990's anymore. Please make these dynamic such that they are never needed (the code figures out the best values), or on some per-device basis using configfs or sysfs. thanks, greg k-h
Re: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module
On Tue, Dec 01, 2020 at 02:34:52PM -0800, mgr...@linux.intel.com wrote: > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -8955,6 +8955,14 @@ M: Deepak Saxena > S: Maintained > F: drivers/char/hw_random/ixp4xx-rng.c > > +INTEL KEEM BAY IPC DRIVER > +M: Daniele Alessandrelli > +M: Mark Gross > +S: Maintained > +F: Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml > +F: drivers/soc/intel/keembay-ipc.c > +F: include/linux/soc/intel/keembay-ipc.h Sad that Intel is not going to actually pay you all to do this maintenance work for a brand new subsystem you are wanting to add to the tree :( Does this mean you all will have to do it on your own time and not as part of your work at Intel? If so, why not just use your personal email addresses instead to make it a bit more obvious? thanks, greg k-h
Re: [PATCH 4.9 00/42] 4.9.247-rc1 review
On Tue, 1 Dec 2020 at 14:26, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.247 release. > There are 42 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, 03 Dec 2020 08:46:29 +. > 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/v4.x/stable-review/patch-4.9.247-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-4.9.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: 4.9.247-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: c2b4ff37ba1a5a9bbb5160e311d472b8185fb347 git describe: v4.9.246-43-gc2b4ff37ba1a Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.246-43-gc2b4ff37ba1a No regressions (compared to build v4.9.246) No fixes (compared to build v4.9.246) Ran 24845 total tests in the following environments and test suites. Environments -- - arm - arm64 - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - mips - qemu-arm64-kasan - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - sparc - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * linux-log-parser * igt-gpu-tools * install-android-platform-tools-r2600 * kvm-unit-tests * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-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-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-tracing-tests * perf * v4l2-compliance * ltp-syscalls-tests * network-basic-tests * ltp-open-posix-tests -- Linaro LKFT https://lkft.linaro.org
Re: UBSAN: array-index-out-of-bounds in arch_uprobe_analyze_insn
Hi Kees,
On Tue, 1 Dec 2020 16:48:55 -0800
Kees Cook wrote:
> Hi,
>
> There appears to be a problem with prefix counting for the instruction
> decoder. It looks like insn_get_prefixes() isn't keeping "nb" and "nbytes"
> in sync correctly:
>
> while (inat_is_legacy_prefix(attr)) {
> /* Skip if same prefix */
> for (i = 0; i < nb; i++)
> if (prefixes->bytes[i] == b)
> goto found;
> if (nb == 4)
> /* Invalid instruction */
> break;
> prefixes->bytes[nb++] = b;
> ...
> found:
> prefixes->nbytes++;
> insn->next_byte++;
> lb = b;
> b = peek_next(insn_byte_t, insn);
> attr = inat_get_opcode_attribute(b);
> }
>
> (nbytes is incremented on repeated prefixes, but "nb" isn't)
>
> However, it looks like nbytes is used as an offset:
>
> static inline int insn_offset_rex_prefix(struct insn *insn)
> {
> return insn->prefixes.nbytes;
> }
> static inline int insn_offset_vex_prefix(struct insn *insn)
> {
> return insn_offset_rex_prefix(insn) + insn->rex_prefix.nbytes;
> }
Yes, it is designed to do that. nbytes counts how many bytes the prefix is,
and nb is how many bytes of the prefix->bytes consumed.
Since the legacy prefix can be repeated and more than 4 (bytes), we can not
store all of those.
>
> Which means everything that iterates over prefixes.bytes[] is buggy,
> since they may be trying to read past the end of the array:
Good catch! All following usage are wrong...
>
> $ git grep -A3 -E '< .*prefixes(\.|->)nbytes'
> boot/compressed/sev-es.c: for (i = 0; i < insn->prefixes.nbytes; i++) {
> boot/compressed/sev-es.c- insn_byte_t p =
> insn->prefixes.bytes[i];
> boot/compressed/sev-es.c-
> boot/compressed/sev-es.c- if (p == 0xf2 || p == 0xf3)
> --
> kernel/uprobes.c: for (i = 0; i < insn->prefixes.nbytes; i++) {
> kernel/uprobes.c- insn_attr_t attr;
> kernel/uprobes.c-
> kernel/uprobes.c- attr =
> inat_get_opcode_attribute(insn->prefixes.bytes[i]);
> --
> kernel/uprobes.c: for (i = 0; i < insn->prefixes.nbytes; i++) {
> kernel/uprobes.c- if (insn->prefixes.bytes[i] == 0x66)
> kernel/uprobes.c- return -ENOTSUPP;
> kernel/uprobes.c- }
> --
> lib/insn-eval.c:for (i = 0; i < insn->prefixes.nbytes; i++) {
> lib/insn-eval.c-insn_byte_t p = insn->prefixes.bytes[i];
> lib/insn-eval.c-
> lib/insn-eval.c-if (p == 0xf2 || p == 0xf3)
> --
> lib/insn-eval.c:for (i = 0; i < insn->prefixes.nbytes; i++) {
> lib/insn-eval.c-insn_attr_t attr;
> lib/insn-eval.c-
> lib/insn-eval.c-attr =
> inat_get_opcode_attribute(insn->prefixes.bytes[i]);
>
> I don't see a clear way to fix this.
For the loop, we can check the insn.prefixes.bytes[i] == 0 since
it is initialized by 0 and 0x0 is not a prefix like this.
for (i = 0; insn->prefixes.bytes[i] && i < 4; i++) {
...
}
Thank you,
>
> -Kees
>
> On Mon, Sep 21, 2020 at 09:20:07PM -0700, syzbot wrote:
> > syzbot has bisected this issue to:
> >
> > commit 4b2bd5fec007a4fd3fc82474b9199af25013de4c
> > Author: John Stultz
> > Date: Sat Oct 8 00:02:33 2016 +
> >
> > proc: fix timerslack_ns CAP_SYS_NICE check when adjusting self
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1697348d90
> > start commit: 325d0eab Merge branch 'akpm' (patches from Andrew)
> > git tree: upstream
> > final oops: https://syzkaller.appspot.com/x/report.txt?x=1597348d90
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1197348d90
> > kernel config: https://syzkaller.appspot.com/x/.config?x=b12e84189082991c
> > dashboard link: https://syzkaller.appspot.com/bug?extid=9b64b619f10f19d19a7c
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1573a8ad90
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=164ee6c590
> >
> > Reported-by: syzbot+9b64b619f10f19d19...@syzkaller.appspotmail.com
> > Fixes: 4b2bd5fec007 ("proc: fix timerslack_ns CAP_SYS_NICE check when
> > adjusting self")
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> --
> Kees Cook
--
Masami Hiramatsu
[PATCH] tty : serial: jsm: Fixed file by adding spacing
Fixed a coding style issue Signed-off-by: Clement Smith --- drivers/tty/serial/jsm/jsm_tty.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/jsm/jsm_tty.c b/drivers/tty/serial/jsm/jsm_tty.c index 689774c073ca..512b77195e9f 100644 --- a/drivers/tty/serial/jsm/jsm_tty.c +++ b/drivers/tty/serial/jsm/jsm_tty.c @@ -607,7 +607,7 @@ void jsm_input(struct jsm_channel *ch) * Give the Linux ld the flags in the * format it likes. */ - if (*(ch->ch_equeue +tail +i) & UART_LSR_BI) + if (*(ch->ch_equeue + tail + i) & UART_LSR_BI) tty_insert_flip_char(port, *(ch->ch_rqueue +tail +i), TTY_BREAK); else if (*(ch->ch_equeue +tail +i) & UART_LSR_PE) tty_insert_flip_char(port, *(ch->ch_rqueue +tail +i), TTY_PARITY); -- 2.27.0
Re: [PATCH bpf-next] kbuild: Restore ability to build out-of-tree modules
On Tue, Dec 01, 2020 at 01:44:46PM -0800, Andrii Nakryiko wrote:
> On Tue, Dec 1, 2020 at 11:32 AM Leon Romanovsky wrote:
> >
> > On Tue, Dec 01, 2020 at 10:01:23AM -0800, Andrii Nakryiko wrote:
> > > On Tue, Dec 1, 2020 at 6:37 AM Leon Romanovsky wrote:
> > > >
> > > > From: Leon Romanovsky
> > > >
> > > > The out-of-tree modules are built without vmlinux target and request
> > > > to recompile that target unconditionally causes to the following
> > > > compilation error.
> > > >
> > > > [root@server kernel]# make
> > > > <..>
> > > > make -f ./scripts/Makefile.modpost
> > > > make -f ./scripts/Makefile.modfinal
> > > > make[3]: *** No rule to make target 'vmlinux', needed by
> > > > '/my_temp/out-of-tree-module/kernel/test.ko'. Stop.
> > > > make[2]: *** [scripts/Makefile.modpost:117: __modpost] Error 2
> > > > make[1]: *** [Makefile:1703: modules] Error 2
> > > > make[1]: Leaving directory
> > > > '/usr/src/kernels/5.10.0-rc5_for_upstream_base_2020_11_29_11_34'
> > > > make: *** [Makefile:80: modules] Error 2
> > > >
> > > > As a solution separate between build paths that has vmlinux target and
> > > > paths without.
> > > >
> > > > Fixes: 5f9ae91f7c0d ("kbuild: Build kernel module BTFs if BTF is
> > > > enabled and pahole supports it")
> > > > Reported-by: Edward Srouji
> > > > Signed-off-by: Leon Romanovsky
> > > > ---
> > >
> > > e732b538f455 ("kbuild: Skip module BTF generation for out-of-tree
> > > external modules") ([0]) was supposed to take care of this. Did you
> > > try it?
> >
> > My tree doesn't have this patch yet, so my questions can be stupid:
> > 1. Will it print "Skipping BTF generation for ... due to unavailability
> > of vmlinux" line if my .config doesn't have "CONFIG_DEBUG_INFO_BTF_MODULES"?
> > I hope it is not.
>
> No, it shouldn't. cmd_btf_ko is only executed if
> CONFIG_DEBUG_INFO_BTF_MODULES is set.
>
> > 2. Reliance on existence of vmlinux can be problematic, no one promises
> > us that "make clean" is called before and there are no other leftovers
> > from previous builds.
>
> In such a case, the worst thing that can happen would be that the
> kernel module will get BTF that doesn't match actual vmlinux BTF, and
> when attempted to load into the kernel BTF will be ignored (with a
> warning). It's not ideal, but I don't know how else we can handle this
> short of just not supporting BTF for out-of-tree modules, which a
> bunch of folks would be disappointed about, I think. I'm open to
> suggestions on how to do it better, though.
You can rely on MODPOST_VMLINUX variable to differentiate between builds
of modules vs. vmlinux. Proper message during kernel boot that vmlinux
BTF doesn't match module can be enough, because in real world you won't
load that recompiled vmlinux without "make install" first.
So right now, from out-of-tree modules perspective, you are testing against
some pseudo-random file.
BTW, I tried your patch with and without vmlinux, it worked, so we are
talking about better-to-fix and not must-to-fix thing.
Thanks
>
>
> >
> > And in general, the idea that such invasive change in build infrastructure
> > came without any Ack from relevant maintainers doesn't look right to me.
> >
> > Thanks
> >
> > >
> > > [0]
> > > https://patchwork.kernel.org/project/netdevbpf/patch/20201121070829.2612884-1-and...@kernel.org/
> > >
> > >
> > > > Not proficient enough in Makefile, but it fixes the issue.
> > > > ---
> > > > scripts/Makefile.modfinal | 5 +
> > > > scripts/Makefile.modpost | 4
> > > > 2 files changed, 9 insertions(+)
> > > >
> > > > diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal
> > > > index 02b892421f7a..8a7d0604e7d0 100644
> > > > --- a/scripts/Makefile.modfinal
> > > > +++ b/scripts/Makefile.modfinal
> > > > @@ -48,9 +48,14 @@ if_changed_except = $(if $(call
> > > > newer_prereqs_except,$(2))$(cmd-check), \
> > > > $(cmd);
> > > > \
> > > > printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd, @:)
> > > >
> > > > +ifdef MODPOST_VMLINUX
> > > > # Re-generate module BTFs if either module's .ko or vmlinux changed
> > > > $(modules): %.ko: %.o %.mod.o scripts/module.lds vmlinux FORCE
> > > > +$(call if_changed_except,ld_ko_o,vmlinux)
> > > > +else
> > > > +$(modules): %.ko: %.o %.mod.o scripts/module.lds FORCE
> > > > + +$(call if_changed_except,ld_ko_o)
> > > > +endif
> > > > ifdef CONFIG_DEBUG_INFO_BTF_MODULES
> > > > +$(if $(newer-prereqs),$(call cmd,btf_ko))
> > > > endif
> > > > diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
> > > > index f54b6ac37ac2..f5aa5b422ad7 100644
> > > > --- a/scripts/Makefile.modpost
> > > > +++ b/scripts/Makefile.modpost
> > > > @@ -114,8 +114,12 @@ targets += $(output-symdump)
> > > >
> > > > __modpost: $(output-symdump)
> > > > ifneq ($(KBUILD_MODPOST_NOFINAL),1)
> > > > +ifdef MODPOST_VMLINUX
> > > > + $(Q)$(MAKE) -f
Re: [PATCH 4.14 00/50] 4.14.210-rc1 review
On Tue, 1 Dec 2020 at 14:28, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.210 release. > There are 50 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, 03 Dec 2020 08:46:29 +. > 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/v4.x/stable-review/patch-4.14.210-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-4.14.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: 4.14.210-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 07930d77d7baeac481d5ec4b88f8b26ac810c4bd git describe: v4.14.209-51-g07930d77d7ba Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.209-51-g07930d77d7ba No regressions (compared to build v4.14.209) No fixes (compared to build v4.14.209) Ran 35483 total tests in the following environments and test suites. Environments -- - arm - arm64 - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - juno-r2-kasan - mips - qemu-arm64-clang - qemu-arm64-kasan - qemu-x86_64-clang - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - sparc - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * linux-log-parser * install-android-platform-tools-r2600 * libhugetlbfs * ltp-commands-tests * ltp-containers-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * perf * ltp-cap_bounds-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-io-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * v4l2-compliance * ltp-fs-tests * ltp-hugetlb-tests * ltp-mm-tests * ltp-open-posix-tests * kvm-unit-tests -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v5 08/11] input: raspberrypi-ts: Release firmware handle when not needed
Hi Nicolas,
On Mon, Nov 23, 2020 at 07:38:29PM +0100, Nicolas Saenz Julienne wrote:
> Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
> interface when unbinding the device.
I do not believe this comment is correct any longer. Otherwise:
Acked-by: Dmitry Torokhov
>
> Signed-off-by: Nicolas Saenz Julienne
>
> ---
>
> Changes since v3:
> - Release firmware handle in probe function
>
> Changes since v2:
> - Use devm_rpi_firmware_get(), instead of remove function
>
> drivers/input/touchscreen/raspberrypi-ts.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/raspberrypi-ts.c
> b/drivers/input/touchscreen/raspberrypi-ts.c
> index ef6aaed217cf..5000f5fd9ec3 100644
> --- a/drivers/input/touchscreen/raspberrypi-ts.c
> +++ b/drivers/input/touchscreen/raspberrypi-ts.c
> @@ -160,7 +160,7 @@ static int rpi_ts_probe(struct platform_device *pdev)
> touchbuf = (u32)ts->fw_regs_phys;
> error = rpi_firmware_property(fw, RPI_FIRMWARE_FRAMEBUFFER_SET_TOUCHBUF,
> , sizeof(touchbuf));
> -
> + rpi_firmware_put(fw);
> if (error || touchbuf != 0) {
> dev_warn(dev, "Failed to set touchbuf, %d\n", error);
> return error;
> --
> 2.29.2
>
--
Dmitry
Re: [PATCH v2 bpf-next 00/13] Atomics for eBPF
On Tue, Dec 1, 2020 at 9:53 PM John Fastabend wrote: > > Yonghong Song wrote: > > > > > > [...] > > > > Great, this means that all existing valid uses of > > > __sync_fetch_and_add() will generate BPF_XADD instructions and will > > > work on old kernels, right? > > > > That is correct. > > > > > > > > If that's the case, do we still need cpu=v4? The new instructions are > > > *only* going to be generated if the user uses previously unsupported > > > __sync_fetch_xxx() intrinsics. So, in effect, the user consciously > > > opts into using new BPF instructions. cpu=v4 seems like an unnecessary > > > tautology then? > > > > This is a very good question. Essentially this boils to when users can > > use the new functionality including meaningful return value of > > __sync_fetch_and_add(). > >(1). user can write a small bpf program to test the feature. If user > > gets a failed compilation (fatal error), it won't be supported. > > Otherwise, it is supported. > >(2). compiler provides some way to tell user it is safe to use, e.g., > > -mcpu=v4, or some clang macro suggested by Brendan earlier. > > > > I guess since kernel already did a lot of feature discovery. Option (1) > > is probably fine. > > For option (2) we can use BTF with kernel version check. If kernel is > greater than kernel this lands in we use the the new instructions if > not we use a slower locked version. That should work for all cases > unless someone backports patches into an older case. Two different things: Clang support detection and kernel support detection. You are talking about kernel detection, I and Yonghong were talking about Clang detection and explicit cpu=v4 opt-in. For kernel detection, if there is an enum value or type that gets added along the feature, then with CO-RE built-ins it's easy to detect and kernel dead code elimination will make sure that unsupported instructions won't trip up the BPF verifier. Still need Clang support to compile the program in the first place, though. If there is no such BTF-based way to check, it is still possible to try to load a trivial BPF program with __sync_fech_and_xxx() to do feature detection and then use .rodata to turn off code paths relying on a new instruction set. > > At least thats what I'll probably end up wrapping in a helper function.
Re: [PATCH v2] venus: vdec: Handle DRC after drain
On Wed, Dec 2, 2020 at 7:34 AM Stanimir Varbanov
wrote:
>
> Hi Fritz,
>
> On 12/1/20 6:23 AM, Fritz Koenig wrote:
> > If the DRC is near the end of the stream the client
> > may send a V4L2_DEC_CMD_STOP before the DRC occurs.
> > V4L2_DEC_CMD_STOP puts the driver into the
> > VENUS_DEC_STATE_DRAIN state. DRC must be aware so
> > that after the DRC event the state can be restored
> > correctly.
> >
> > Signed-off-by: Fritz Koenig
> > ---
> >
> > v2: remove TODO
> >
> > drivers/media/platform/qcom/venus/core.h | 1 +
> > drivers/media/platform/qcom/venus/vdec.c | 17 +++--
> > 2 files changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/platform/qcom/venus/core.h
> > b/drivers/media/platform/qcom/venus/core.h
> > index 2b0899bf5b05f..1680c936c06fb 100644
> > --- a/drivers/media/platform/qcom/venus/core.h
> > +++ b/drivers/media/platform/qcom/venus/core.h
> > @@ -406,6 +406,7 @@ struct venus_inst {
> > unsigned int core_acquired: 1;
> > unsigned int bit_depth;
> > bool next_buf_last;
> > + bool drain_active;
>
> Could you introduce a new codec state instead of adding a flag for such
> corner case.
>
> I think that we will need to handle at least one more corner case (DRC
> during seek operation),
Just happen to have posted a patch for that. :)
https://lkml.org/lkml/2020/12/2/24
> so then we have to introduce another flag, and
> this is not a good solution to me. These additional flags will
> complicate the state handling and will make the code readability worst
>
> I'd introduce: VENUS_DEC_STATE_DRC_DURING_DRAIN or something similar.
I'm wondering what is the best approach here. As you see in my patch,
I did not have to introduce a new state but relied instead on the
state of next_buf_last (which may or may not be correct - maybe we can
think of a way to merge both patches into one?). Flushes, either
explicit or implicitly triggered by a DRC, are more than a state by
themselves but rather an extra dimension from which other states can
still apply. I'm afraid we already have many states as it is and
adding more might add complexity.
A lot of the recent issues we had came from that number of states,
notably from the fact that not all states are always tested when they
should (and fall back to the default: branch of a switch case that
does nothing). I think we could improve the robustness of this driver
if we mandate that each state check must be done using a switch
statement without a default: branch. That would force us to ensure
that each newly introduced state is considered in every situation
where it might be relevant.
>
> > };
> >
> > #define IS_V1(core) ((core)->res->hfi_version == HFI_VERSION_1XX)
> > diff --git a/drivers/media/platform/qcom/venus/vdec.c
> > b/drivers/media/platform/qcom/venus/vdec.c
> > index 5671cf3458a68..1d551b4d651a8 100644
> > --- a/drivers/media/platform/qcom/venus/vdec.c
> > +++ b/drivers/media/platform/qcom/venus/vdec.c
> > @@ -523,8 +523,10 @@ vdec_decoder_cmd(struct file *file, void *fh, struct
> > v4l2_decoder_cmd *cmd)
> >
> > ret = hfi_session_process_buf(inst, );
> >
> > - if (!ret && inst->codec_state == VENUS_DEC_STATE_DECODING)
> > + if (!ret && inst->codec_state == VENUS_DEC_STATE_DECODING) {
> > inst->codec_state = VENUS_DEC_STATE_DRAIN;
> > + inst->drain_active = true;
> > + }
> > }
> >
> > unlock:
> > @@ -976,10 +978,14 @@ static int vdec_start_capture(struct venus_inst *inst)
> >
> > inst->codec_state = VENUS_DEC_STATE_DECODING;
> >
> > + if (inst->drain_active)
> > + inst->codec_state = VENUS_DEC_STATE_DRAIN;
> > +
> > inst->streamon_cap = 1;
> > inst->sequence_cap = 0;
> > inst->reconfig = false;
> > inst->next_buf_last = false;
> > + inst->drain_active = false;
> >
> > return 0;
> >
> > @@ -1105,6 +,7 @@ static int vdec_stop_capture(struct venus_inst *inst)
> > /* fallthrough */
> > case VENUS_DEC_STATE_DRAIN:
> > inst->codec_state = VENUS_DEC_STATE_STOPPED;
> > + inst->drain_active = false;
> > /* fallthrough */
> > case VENUS_DEC_STATE_SEEK:
> > vdec_cancel_dst_buffers(inst);
> > @@ -1304,8 +1311,10 @@ static void vdec_buf_done(struct venus_inst *inst,
> > unsigned int buf_type,
> >
> > v4l2_event_queue_fh(>fh, );
> >
> > - if (inst->codec_state == VENUS_DEC_STATE_DRAIN)
> > + if (inst->codec_state == VENUS_DEC_STATE_DRAIN) {
> > + inst->drain_active = false;
> > inst->codec_state = VENUS_DEC_STATE_STOPPED;
> > + }
> > }
> >
> > if (!bytesused)
> > @@ -1429,9 +1438,13 @@ static void vdec_event_notify(struct venus_inst
> > *inst, u32 event,
> > case EVT_SYS_EVENT_CHANGE:
> >
Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance
On Wed, Dec 02, 2020 at 12:18:36PM +0800, Jason Wang wrote:
>
> On 2020/12/1 下午5:23, Cindy Lu wrote:
> > On Mon, Nov 30, 2020 at 11:33 PM Michael S. Tsirkin wrote:
> > > On Mon, Nov 30, 2020 at 06:41:45PM +0800, Cindy Lu wrote:
> > > > On Mon, Nov 30, 2020 at 5:33 PM Michael S. Tsirkin
> > > > wrote:
> > > > > On Mon, Nov 30, 2020 at 11:27:59AM +0200, Eli Cohen wrote:
> > > > > > On Mon, Nov 30, 2020 at 04:00:51AM -0500, Michael S. Tsirkin wrote:
> > > > > > > On Mon, Nov 30, 2020 at 08:27:46AM +0200, Eli Cohen wrote:
> > > > > > > > On Sun, Nov 29, 2020 at 03:08:22PM -0500, Michael S. Tsirkin
> > > > > > > > wrote:
> > > > > > > > > On Sun, Nov 29, 2020 at 08:43:51AM +0200, Eli Cohen wrote:
> > > > > > > > > > We should not try to use the VF MAC address as that is used
> > > > > > > > > > by the
> > > > > > > > > > regular (e.g. mlx5_core) NIC implementation. Instead, use a
> > > > > > > > > > random
> > > > > > > > > > generated MAC address.
> > > > > > > > > >
> > > > > > > > > > Suggested by: Cindy Lu
> > > > > > > > > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for
> > > > > > > > > > supported mlx5 devices")
> > > > > > > > > > Signed-off-by: Eli Cohen
> > > > > > > > > I didn't realise it's possible to use VF in two ways
> > > > > > > > > with and without vdpa.
> > > > > > > > Using a VF you can create quite a few resources, e.g. send
> > > > > > > > queues
> > > > > > > > recieve queues, virtio_net queues etc. So you can possibly
> > > > > > > > create
> > > > > > > > several instances of vdpa net devices and nic net devices.
> > > > > > > >
> > > > > > > > > Could you include a bit more description on the failure
> > > > > > > > > mode?
> > > > > > > > Well, using the MAC address of the nic vport is wrong since
> > > > > > > > that is the
> > > > > > > > MAC of the regular NIC implementation of mlx5_core.
> > > > > > > Right but ATM it doesn't coexist with vdpa so what's the problem?
> > > > > > >
> > > > > > This call is wrong: mlx5_query_nic_vport_mac_address()
> > > > > >
> > > > > > > > > Is switching to a random mac for such an unusual
> > > > > > > > > configuration really justified?
> > > > > > > > Since I can't use the NIC's MAC address, I have two options:
> > > > > > > > 1. To get the MAC address as was chosen by the user
> > > > > > > > administering the
> > > > > > > > NIC. This should invoke the set_config callback.
> > > > > > > > Unfortunately this
> > > > > > > > is not implemented yet.
> > > > > > > >
> > > > > > > > 2. Use a random MAC address. This is OK since if (1) is
> > > > > > > > implemented it
> > > > > > > > can always override this random configuration.
> > > > > > > >
> > > > > > > > > It looks like changing a MAC could break some guests,
> > > > > > > > > can it not?
> > > > > > > > >
> > > > > > > > No, it will not. The current version of mlx5 VDPA does not
> > > > > > > > allow regular
> > > > > > > > NIC driver and VDPA to co-exist. I have patches ready that
> > > > > > > > enable that
> > > > > > > > from steering point of view. I will post them here once other
> > > > > > > > patches on
> > > > > > > > which they depend will be merged.
> > > > > > > >
> > > > > > > > https://patchwork.ozlabs.org/project/netdev/patch/20201120230339.651609-12-sae...@nvidia.com/
> > > > > > > Could you be more explicit on the following points:
> > > > > > > - which configuration is broken ATM (as in, two device have
> > > > > > > identical
> > > > > > >macs? any other issues)?
> > > > > > The only wrong thing is the call to
> > > > > > mlx5_query_nic_vport_mac_address().
> > > > > > It's not breaking anything yet is wrong. The random MAC address
> > > > > > setting
> > > > > > is required for the steering patches.
> > > > > Okay so I'm not sure the Fixes tag at least is appropriate if it's a
> > > > > dependency of a new feature.
> > > > >
> > > > > > > - why won't device MAC change from guest point of view?
> > > > > > >
> > > > > > It's lack of implementation in qemu as far as I know.
> > > > > Sorry not sure I understand. What's not implemented in QEMU?
> > > > >
> > > > HI Michael, there are some bug in qemu to set_config, this will fix in
> > > > future,
> > > > But this patch is still needed, because without this patch the mlx
> > > > driver will give an 0 mac address to qemu
> > > > and qemu will overwrite the default mac address. This will cause
> > > > traffic down.
> > > Hmm the patch description says VF mac address, not 0 address. Confused.
> > > If there's no mac we can clear VIRTIO_NET_F_MAC and have guest
> > > use a random value ...
>
>
> I'm not sure this can work for all types of vDPA (e.g it could not be a
> learning bridge in the swtich).
>
>
> > >
> > hi Michael，
> > I have tried as your suggestion, seems even remove the
> > VIRTIO_NET_F_MAC the qemu will still call get_cinfig and overwrite the
> > default address in VM,
>
>
> This looks a bug in qemu, in guest driver we had:
>
> /*
Re: [PATCH] x86, build: remove -m16 workaround for unsupported versions of GCC
On November 30, 2020 5:13:06 PM PST, Nick Desaulniers
wrote:
>A revert of the following two commits.
>commit de3accdaec88 ("x86, build: Build 16-bit code with -m16 where
>possible")
>commit a9cfccee6604 ("x86, build: Change code16gcc.h from a C header to
>an assembly header")
>
>Since commit 0bddd227f3dc ("Documentation: update for gcc 4.9
>requirement") the minimum supported version of GCC is gcc-4.9. It's
>now
>safe to remove this code.
>
>Signed-off-by: Nick Desaulniers
>---
> arch/x86/Makefile | 9 +
> arch/x86/boot/code16gcc.h | 12
> 2 files changed, 1 insertion(+), 20 deletions(-)
> delete mode 100644 arch/x86/boot/code16gcc.h
>
>diff --git a/arch/x86/Makefile b/arch/x86/Makefile
>index 1bf21746f4ce..7116da3980be 100644
>--- a/arch/x86/Makefile
>+++ b/arch/x86/Makefile
>@@ -24,14 +24,7 @@ endif
>
># How to compile the 16-bit code. Note we always compile for
>-march=i386;
> # that way we can complain to the user if the CPU is insufficient.
>-#
>-# The -m16 option is supported by GCC >= 4.9 and clang >= 3.5. For
>-# older versions of GCC, include an *assembly* header to make sure
>that
>-# gcc doesn't play any games behind our back.
>-CODE16GCC_CFLAGS := -m32 -Wa,$(srctree)/arch/x86/boot/code16gcc.h
>-M16_CFLAGS := $(call cc-option, -m16, $(CODE16GCC_CFLAGS))
>-
>-REALMODE_CFLAGS := $(M16_CFLAGS) -g -Os -DDISABLE_BRANCH_PROFILING \
>+REALMODE_CFLAGS := -m16 -g -Os -DDISABLE_BRANCH_PROFILING \
> -Wall -Wstrict-prototypes -march=i386 -mregparm=3 \
> -fno-strict-aliasing -fomit-frame-pointer -fno-pic \
> -mno-mmx -mno-sse
>diff --git a/arch/x86/boot/code16gcc.h b/arch/x86/boot/code16gcc.h
>deleted file mode 100644
>index e19fd7536307..
>--- a/arch/x86/boot/code16gcc.h
>+++ /dev/null
>@@ -1,12 +0,0 @@
>-/* SPDX-License-Identifier: GPL-2.0 */
>-#
>-# code16gcc.h
>-#
>-# This file is added to the assembler via -Wa when compiling 16-bit C
>code.
>-# This is done this way instead via asm() to make sure gcc does not
>reorder
>-# things around us.
>-#
>-# gcc 4.9+ has a real -m16 option so we can drop this hack long term.
>-#
>-
>- .code16gcc
With enthusiasm:
Acked-by: H. Peter Anvin
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH v2 bpf-next 00/13] Atomics for eBPF
Yonghong Song wrote: > > [...] > > Great, this means that all existing valid uses of > > __sync_fetch_and_add() will generate BPF_XADD instructions and will > > work on old kernels, right? > > That is correct. > > > > > If that's the case, do we still need cpu=v4? The new instructions are > > *only* going to be generated if the user uses previously unsupported > > __sync_fetch_xxx() intrinsics. So, in effect, the user consciously > > opts into using new BPF instructions. cpu=v4 seems like an unnecessary > > tautology then? > > This is a very good question. Essentially this boils to when users can > use the new functionality including meaningful return value of > __sync_fetch_and_add(). >(1). user can write a small bpf program to test the feature. If user > gets a failed compilation (fatal error), it won't be supported. > Otherwise, it is supported. >(2). compiler provides some way to tell user it is safe to use, e.g., > -mcpu=v4, or some clang macro suggested by Brendan earlier. > > I guess since kernel already did a lot of feature discovery. Option (1) > is probably fine. For option (2) we can use BTF with kernel version check. If kernel is greater than kernel this lands in we use the the new instructions if not we use a slower locked version. That should work for all cases unless someone backports patches into an older case. At least thats what I'll probably end up wrapping in a helper function.
Re: [PATCH v2 bpf-next 10/13] bpf: Add instructions for atomic[64]_[fetch_]sub
On Tue, Dec 1, 2020 at 4:38 AM Brendan Jackman wrote: > > I guess it's also worth remembering other archs might have an atomic > subtract. which one? arm64 LSE implements atomic_fetch_sub as neg+ldadd. imo x64 and arm64 example outweighs choices by other archs if there are such. Even without LSE it will be neg+llsc loop. The reason I proposed bpf xsub insn earlier is that I thought that llvm won't be able to emit it so easily and JIT/verifier would struggle.
Re: [PATCH v2 bpf-next 02/13] bpf: x86: Factor out emission of REX byte
On Tue, Dec 1, 2020 at 4:12 AM Brendan Jackman wrote: > > On Sat, Nov 28, 2020 at 05:14:05PM -0800, Alexei Starovoitov wrote: > > On Fri, Nov 27, 2020 at 05:57:27PM +, Brendan Jackman wrote: > > > The JIT case for encoding atomic ops is about to get more > > > complicated. In order to make the review & resulting code easier, > > > let's factor out some shared helpers. > > > > > > Signed-off-by: Brendan Jackman > > > --- > > > arch/x86/net/bpf_jit_comp.c | 39 ++--- > > > 1 file changed, 23 insertions(+), 16 deletions(-) > > > > > > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c > > > index 94b17bd30e00..a839c1a54276 100644 > > > --- a/arch/x86/net/bpf_jit_comp.c > > > +++ b/arch/x86/net/bpf_jit_comp.c > > > @@ -702,6 +702,21 @@ static void emit_modrm_dstoff(u8 **pprog, u32 r1, > > > u32 r2, int off) > > > *pprog = prog; > > > } > > > > > > +/* > > > + * Emit a REX byte if it will be necessary to address these registers > > > > What is "REX byte" ? > > May be rename it to maybe_emit_mod() ? > > Er, this is the REX prefix as described in > https://wiki.osdev.org/X86-64_Instruction_Encoding#REX_prefix > > Would maybe_emit_mod be accurate? In my mind "mod" is a field in the > ModR/M byte which comes _after_ the opcode. Before developing this > patchset I knew almost nothing about x86, so maybe I'm missing something > about the general terminology? I wrote the JIT without looking into the manual and without studying the terminology. Why? Because it was not necessary. I still don't see a reason why that obscure terminology needs to be brought in into the code. 'mod' to me is a 'modifier'. Nothing to do with intel's modrm thing.
Re: [PATCH v2 bpf-next 01/13] bpf: x86: Factor out emission of ModR/M for *(reg + off)
On Tue, Dec 1, 2020 at 4:14 AM Brendan Jackman wrote: > > On Sat, Nov 28, 2020 at 05:15:52PM -0800, Alexei Starovoitov wrote: > > On Fri, Nov 27, 2020 at 05:57:26PM +, Brendan Jackman wrote: > > > +/* Emit the ModR/M byte for addressing *(r1 + off) and r2 */ > > > +static void emit_modrm_dstoff(u8 **pprog, u32 r1, u32 r2, int off) > > > > same concern as in the another patch. If you could avoid intel's puzzling > > names > > like above it will make reviewing the patch easier. > > In this case there is actually a call like > > emit_modrm_dstoff(, src_reg, dst_reg) emit_insn_prefix() ?
Re: [PATCH v7 00/17] Add support for Clang LTO
On Tue, Dec 1, 2020 at 6:43 PM Masahiro Yamada wrote: > > On Wed, Dec 2, 2020 at 2:31 AM Kees Cook wrote: > > > > On Mon, Nov 30, 2020 at 12:01:31PM +, Will Deacon wrote: > > > Hi Sami, > > > > > > On Wed, Nov 18, 2020 at 02:07:14PM -0800, Sami Tolvanen wrote: > > > > This patch series adds support for building the kernel with Clang's > > > > Link Time Optimization (LTO). In addition to performance, the primary > > > > motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to > > > > be used in the kernel. Google has shipped millions of Pixel devices > > > > running three major kernel versions with LTO+CFI since 2018. > > > > > > > > Most of the patches are build system changes for handling LLVM bitcode, > > > > which Clang produces with LTO instead of ELF object files, postponing > > > > ELF processing until a later stage, and ensuring initcall ordering. > > > > > > > > Note that v7 brings back arm64 support as Will has now staged the > > > > prerequisite memory ordering patches [1], and drops x86_64 while we work > > > > on fixing the remaining objtool warnings [2]. > > > > > > Sounds like you're going to post a v8, but that's the plan for merging > > > that? The arm64 parts look pretty good to me now. > > > > I haven't seen Masahiro comment on this in a while, so given the review > > history and its use (for years now) in Android, I will carry v8 (assuming > > all is fine with it) it in -next unless there are objections. > > > What I dislike about this implementation is > it cannot drop any unreachable function/data. > (and it is completely different from GCC LTO) > > This is not real LTO. I'm not sure I understand your concern. LTO cannot drop functions or data from vmlinux.o that may be referenced externally. However, with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, the linker certainly can drop unused functions and data when linking vmlinux, and there's no reason this option can't be used together with LTO. In fact, Pixel 3 does enable this option, but in our experience, there isn't much unused code or data to remove, so later devices no longer use it. There's technically no reason why we couldn't postpone LTO until we link vmlinux instead, and thus allow the linker to possibly remove more unused code without the help of --gc-sections, but at least with the current build process, that would involve performing the slow LTO link step multiple times, which isn't worth it when we can get the performance benefits (and CFI) already when linking vmlinux.o with LTO. Sami
Re: memory leak in gs_start_io
On Tue, Dec 01, 2020 at 11:45:20PM -0500, Ertza Warraich wrote: > We report a memory leak bug (in linux-5.8.13) found by FuzzUSB (a modified > version of syzkaller). > > The bug report is as follows: > == > BUG: memory leak > unreferenced object 0x888069c12000 (size 128): > comm "c4_fuzz", pid 2628, jiffies 4294945547 (age 774.450s) > hex dump (first 32 bytes): > b8 80 48 65 80 88 ff ff 00 7c f9 5b 80 88 ff ff ..He.|.[ > 00 7c af 64 80 88 ff ff 00 02 00 00 00 00 00 00 .|.d > backtrace: > [<8f105b01>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 > [inline] > [<8f105b01>] slab_post_alloc_hook mm/slab.h:588 [inline] > [<8f105b01>] slab_alloc_node mm/slub.c:2824 [inline] > [<8f105b01>] slab_alloc mm/slub.c:2832 [inline] > [<8f105b01>] kmem_cache_alloc_trace+0xfe/0x330 mm/slub.c:2849 > [<81072efc>] kmalloc include/linux/slab.h:555 [inline] > [<81072efc>] kzalloc include/linux/slab.h:669 [inline] > [<81072efc>] dummy_alloc_request+0xa0/0x190 > drivers/usb/gadget/udc/dummy_hcd.c:663 > [] usb_ep_alloc_request+0x65/0x2c0 > drivers/usb/gadget/udc/core.c:178 > [<6b6ab221>] gs_alloc_req+0x28/0xd0 > drivers/usb/gadget/function/u_serial.c:166 > [<999f9b54>] gs_alloc_requests+0x207/0x2f0 > drivers/usb/gadget/function/u_serial.c:517 > [ ] gs_start_io+0x134/0x2a0 > drivers/usb/gadget/function/u_serial.c:555 > [ ] gs_open+0x323/0x440 > drivers/usb/gadget/function/u_serial.c:640 > [ ] tty_open+0x23c/0x870 drivers/tty/tty_io.c:2048 > [<01954030>] chrdev_open+0x1e9/0x5b0 fs/char_dev.c:414 > [<2321ec1f>] do_dentry_open+0x434/0xf40 fs/open.c:828 > [<0de9bc50>] vfs_open+0x9a/0xc0 fs/open.c:942 > [ ] do_open fs/namei.c:3243 [inline] > [ ] path_openat+0x1658/0x2570 fs/namei.c:3360 > [ ] do_filp_open+0x15e/0x210 fs/namei.c:3387 > [<793cea2f>] do_sys_openat2+0x2e0/0x570 fs/open.c:1179 > [<67f289f1>] do_sys_open+0x88/0xc0 fs/open.c:1195 > [<937c31df>] ksys_open include/linux/syscalls.h:1388 [inline] > [<937c31df>] __do_sys_open fs/open.c:1201 [inline] > [<937c31df>] __se_sys_open fs/open.c:1199 [inline] > [<937c31df>] __x64_sys_open+0x79/0xb0 fs/open.c:1199 > == Nice, care to make up a fix for this now that you have a reproducer? thanks, greg k-h
