* Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
From: Bjorn Helgaas @ 2020-07-16 23:54 UTC (permalink / raw)
To: Karol Herbst
Cc: Sasha Levin, Patrick Volkerding, Linux PCI, linux-kernel,
dri-devel, Kai-Heng Feng, Ben Skeggs, nouveau, Bjorn Helgaas,
Mika Westerberg
In-Reply-To: <CACO55tuA+XMgv=GREf178NzTLTHri4kyD5mJjKuDpKxExauvVg@mail.gmail.com>
[+cc Sasha -- stable kernel regression]
[+cc Patrick, Kai-Heng, LKML]
On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst <kherbst@redhat.com> wrote:
> >
> > Hi everybody,
> >
> > with the mentioned commit Nouveau isn't able to load firmware onto the
> > GPU on one of my systems here. Even though the issue doesn't always
> > happen I am quite confident this is the commit breaking it.
> >
> > I am still digging into the issue and trying to figure out what
> > exactly breaks, but it shows up in different ways. Either we are not
> > able to boot the engines on the GPU or the GPU becomes unresponsive.
> > Btw, this is also a system where our runtime power management issue
> > shows up, so maybe there is indeed something funky with the bridge
> > controller.
> >
> > Just pinging you in case you have an idea on how this could break Nouveau
> >
> > most of the times it shows up like this:
> > nouveau 0000:01:00.0: acr: AHESASC binary failed
> >
> > Sometimes it works at boot and fails at runtime resuming with random
> > faults. So I will be investigating a bit more, but yeah... I am super
> > sure the commit triggered this issue, no idea if it actually causes
> > it.
>
> so yeah.. I reverted that locally and never ran into issues again.
> Still valid on latest 5.7. So can we get this reverted or properly
> fixed? This breaks runtime pm for us on at least some hardware.
Yeah, that stinks. We had another similar report from Patrick:
https://lore.kernel.org/r/CAErSpo5sTeK_my1dEhWp7aHD0xOp87+oHYWkTjbL7ALgDbXo-Q@mail.gmail.com
Apparently the problem is ec411e02b7a2 ("PCI/PM: Assume ports without
DLL Link Active train links in 100 ms"), which Patrick found was
backported to v5.4.49 as 828b192c57e8, and you found was backported to
v5.7.6 as afaff825e3a4.
Oddly, Patrick reported that v5.7.7 worked correctly, even though it
still contains afaff825e3a4.
I guess in the absence of any other clues we'll have to revert it.
I hate to do that because that means we'll have slow resume of
Thunderbolt-connected devices again, but that's better than having
GPUs completely broken.
Could you and Patrick open bugzilla.kernel.org reports, attach dmesg
logs and "sudo lspci -vv" output, and add the URLs to Kai-Heng's
original report at https://bugzilla.kernel.org/show_bug.cgi?id=206837
and to this thread?
There must be a way to fix the slow resume problem without breaking
the GPUs.
Bjorn
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
From: Bjorn Helgaas @ 2020-07-16 23:54 UTC (permalink / raw)
To: Karol Herbst
Cc: Linux PCI, Mika Westerberg, Ben Skeggs, Bjorn Helgaas, Lyude Paul,
nouveau, dri-devel, Patrick Volkerding, linux-kernel,
Kai-Heng Feng, Sasha Levin
In-Reply-To: <CACO55tuA+XMgv=GREf178NzTLTHri4kyD5mJjKuDpKxExauvVg@mail.gmail.com>
[+cc Sasha -- stable kernel regression]
[+cc Patrick, Kai-Heng, LKML]
On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst <kherbst@redhat.com> wrote:
> >
> > Hi everybody,
> >
> > with the mentioned commit Nouveau isn't able to load firmware onto the
> > GPU on one of my systems here. Even though the issue doesn't always
> > happen I am quite confident this is the commit breaking it.
> >
> > I am still digging into the issue and trying to figure out what
> > exactly breaks, but it shows up in different ways. Either we are not
> > able to boot the engines on the GPU or the GPU becomes unresponsive.
> > Btw, this is also a system where our runtime power management issue
> > shows up, so maybe there is indeed something funky with the bridge
> > controller.
> >
> > Just pinging you in case you have an idea on how this could break Nouveau
> >
> > most of the times it shows up like this:
> > nouveau 0000:01:00.0: acr: AHESASC binary failed
> >
> > Sometimes it works at boot and fails at runtime resuming with random
> > faults. So I will be investigating a bit more, but yeah... I am super
> > sure the commit triggered this issue, no idea if it actually causes
> > it.
>
> so yeah.. I reverted that locally and never ran into issues again.
> Still valid on latest 5.7. So can we get this reverted or properly
> fixed? This breaks runtime pm for us on at least some hardware.
Yeah, that stinks. We had another similar report from Patrick:
https://lore.kernel.org/r/CAErSpo5sTeK_my1dEhWp7aHD0xOp87+oHYWkTjbL7ALgDbXo-Q@mail.gmail.com
Apparently the problem is ec411e02b7a2 ("PCI/PM: Assume ports without
DLL Link Active train links in 100 ms"), which Patrick found was
backported to v5.4.49 as 828b192c57e8, and you found was backported to
v5.7.6 as afaff825e3a4.
Oddly, Patrick reported that v5.7.7 worked correctly, even though it
still contains afaff825e3a4.
I guess in the absence of any other clues we'll have to revert it.
I hate to do that because that means we'll have slow resume of
Thunderbolt-connected devices again, but that's better than having
GPUs completely broken.
Could you and Patrick open bugzilla.kernel.org reports, attach dmesg
logs and "sudo lspci -vv" output, and add the URLs to Kai-Heng's
original report at https://bugzilla.kernel.org/show_bug.cgi?id=206837
and to this thread?
There must be a way to fix the slow resume problem without breaking
the GPUs.
Bjorn
^ permalink raw reply
* Re: [PATCH v2] binder: Don't use mmput() from shrinker function.
From: Todd Kjos @ 2020-07-16 23:53 UTC (permalink / raw)
To: Michal Hocko
Cc: Tetsuo Handa, Greg Kroah-Hartman, Arve Hjonnevag, Todd Kjos,
Martijn Coenen, Joel Fernandes, Christian Brauner, syzbot, acme,
alexander.shishkin, jolsa, LKML, Mark Rutland, Ingo Molnar,
namhyung, Peter Zijlstra, syzkaller-bugs,
open list:ANDROID DRIVERS, linux-mm
In-Reply-To: <20200716151756.GO31089@dhcp22.suse.cz>
On Thu, Jul 16, 2020 at 8:18 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Fri 17-07-20 00:12:15, Tetsuo Handa wrote:
> > syzbot is reporting that mmput() from shrinker function has a risk of
> > deadlock [1], for delayed_uprobe_add() from update_ref_ctr() calls
> > kzalloc(GFP_KERNEL) with delayed_uprobe_lock held, and
> > uprobe_clear_state() from __mmput() also holds delayed_uprobe_lock.
> >
> > Commit a1b2289cef92ef0e ("android: binder: drop lru lock in isolate
> > callback") replaced mmput() with mmput_async() in order to avoid sleeping
> > with spinlock held. But this patch replaces mmput() with mmput_async() in
> > order not to start __mmput() from shrinker context.
> >
> > [1] https://syzkaller.appspot.com/bug?id=bc9e7303f537c41b2b0cc2dfcea3fc42964c2d45
> >
> > Reported-by: syzbot <syzbot+1068f09c44d151250c33@syzkaller.appspotmail.com>
> > Reported-by: syzbot <syzbot+e5344baa319c9a96edec@syzkaller.appspotmail.com>
> > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>
> Reviewed-by: Michal Hocko <mhocko@suse.com>
Acked-by: Todd Kjos <tkjos@google.com>
>
> Thanks!
>
> > ---
> > drivers/android/binder_alloc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
> > index 42c672f1584e..cbe6aa77d50d 100644
> > --- a/drivers/android/binder_alloc.c
> > +++ b/drivers/android/binder_alloc.c
> > @@ -947,7 +947,7 @@ enum lru_status binder_alloc_free_page(struct list_head *item,
> > trace_binder_unmap_user_end(alloc, index);
> > }
> > mmap_read_unlock(mm);
> > - mmput(mm);
> > + mmput_async(mm);
> >
> > trace_binder_unmap_kernel_start(alloc, index);
> >
> > --
> > 2.18.4
>
> --
> Michal Hocko
> SUSE Labs
^ permalink raw reply
* Re: [PATCH] mm: thp: Replace HTTP links with HTTPS ones
From: Andrew Morton @ 2020-07-16 23:52 UTC (permalink / raw)
To: Vlastimil Babka; +Cc: Alexander A. Klimov, linux-mm, linux-kernel
In-Reply-To: <642ab4dc-d0fb-d973-0e5e-7d1bc7d90f11@suse.cz>
On Tue, 14 Jul 2020 11:41:37 +0200 Vlastimil Babka <vbabka@suse.cz> wrote:
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -2069,7 +2069,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
> > * free), userland could trigger a small page size TLB miss on the
> > * small sized TLB while the hugepage TLB entry is still established in
> > * the huge TLB. Some CPU doesn't like that.
> > - * See http://support.amd.com/us/Processor_TechDocs/41322.pdf, Erratum
> > + * See https://support.amd.com/us/Processor_TechDocs/41322.pdf, Erratum
> > * 383 on page 93. Intel should be safe but is also warns that it's
>
> Well, it was a good opportunity to find out that the link doesn't work anyway.
> The pdf seems to be now at
> http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf
> and the erratum is on page 105
Thanks.
From: Andrew Morton <akpm@linux-foundation.org>
Subject: mm-thp-replace-http-links-with-https-ones-fix
fix amd.com URL, per Vlastimil
Cc: "Alexander A. Klimov" <grandmaster@al2klimov.de>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/huge_memory.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/mm/huge_memory.c~mm-thp-replace-http-links-with-https-ones-fix
+++ a/mm/huge_memory.c
@@ -2065,8 +2065,8 @@ static void __split_huge_pmd_locked(stru
* free), userland could trigger a small page size TLB miss on the
* small sized TLB while the hugepage TLB entry is still established in
* the huge TLB. Some CPU doesn't like that.
- * See https://support.amd.com/us/Processor_TechDocs/41322.pdf, Erratum
- * 383 on page 93. Intel should be safe but is also warns that it's
+ * See http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf, Erratum
+ * 383 on page 105. Intel should be safe but is also warns that it's
* only safe if the permission and cache attributes of the two entries
* loaded in the two TLB is identical (which should be the case here).
* But it is generally safer to never allow small and huge TLB entries
_
^ permalink raw reply
* [PATCH v3 bpf-next 1/2] bpf: separate bpf_get_[stack|stackid] for perf events BPF
From: Song Liu @ 2020-07-16 22:59 UTC (permalink / raw)
To: linux-kernel, bpf, netdev
Cc: ast, daniel, kernel-team, john.fastabend, kpsingh, brouer, peterz,
Song Liu
In-Reply-To: <20200716225933.196342-1-songliubraving@fb.com>
Calling get_perf_callchain() on perf_events from PEBS entries may cause
unwinder errors. To fix this issue, the callchain is fetched early. Such
perf_events are marked with __PERF_SAMPLE_CALLCHAIN_EARLY.
Similarly, calling bpf_get_[stack|stackid] on perf_events from PEBS may
also cause unwinder errors. To fix this, add separate version of these
two helpers, bpf_get_[stack|stackid]_pe. These two hepers use callchain in
bpf_perf_event_data_kern->data->callchain.
Signed-off-by: Song Liu <songliubraving@fb.com>
---
include/linux/bpf.h | 2 +
kernel/bpf/stackmap.c | 202 +++++++++++++++++++++++++++++++++++----
kernel/trace/bpf_trace.c | 4 +-
3 files changed, 188 insertions(+), 20 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 54ad426dbea1a..cf8804e302257 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -1643,6 +1643,8 @@ extern const struct bpf_func_proto bpf_get_current_comm_proto;
extern const struct bpf_func_proto bpf_get_stackid_proto;
extern const struct bpf_func_proto bpf_get_stack_proto;
extern const struct bpf_func_proto bpf_get_task_stack_proto;
+extern const struct bpf_func_proto bpf_get_stackid_proto_pe;
+extern const struct bpf_func_proto bpf_get_stack_proto_pe;
extern const struct bpf_func_proto bpf_sock_map_update_proto;
extern const struct bpf_func_proto bpf_sock_hash_update_proto;
extern const struct bpf_func_proto bpf_get_current_cgroup_id_proto;
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 48d8e739975fa..7a03d1c24b25f 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -4,6 +4,7 @@
#include <linux/bpf.h>
#include <linux/jhash.h>
#include <linux/filter.h>
+#include <linux/kernel.h>
#include <linux/stacktrace.h>
#include <linux/perf_event.h>
#include <linux/elf.h>
@@ -387,11 +388,10 @@ get_callchain_entry_for_task(struct task_struct *task, u32 init_nr)
#endif
}
-BPF_CALL_3(bpf_get_stackid, struct pt_regs *, regs, struct bpf_map *, map,
- u64, flags)
+static long __bpf_get_stackid(struct bpf_map *map,
+ struct perf_callchain_entry *trace, u64 flags)
{
struct bpf_stack_map *smap = container_of(map, struct bpf_stack_map, map);
- struct perf_callchain_entry *trace;
struct stack_map_bucket *bucket, *new_bucket, *old_bucket;
u32 max_depth = map->value_size / stack_map_data_size(map);
/* stack_map_alloc() checks that max_depth <= sysctl_perf_event_max_stack */
@@ -399,21 +399,9 @@ BPF_CALL_3(bpf_get_stackid, struct pt_regs *, regs, struct bpf_map *, map,
u32 skip = flags & BPF_F_SKIP_FIELD_MASK;
u32 hash, id, trace_nr, trace_len;
bool user = flags & BPF_F_USER_STACK;
- bool kernel = !user;
u64 *ips;
bool hash_matches;
- if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER_STACK |
- BPF_F_FAST_STACK_CMP | BPF_F_REUSE_STACKID)))
- return -EINVAL;
-
- trace = get_perf_callchain(regs, init_nr, kernel, user,
- sysctl_perf_event_max_stack, false, false);
-
- if (unlikely(!trace))
- /* couldn't fetch the stack trace */
- return -EFAULT;
-
/* get_perf_callchain() guarantees that trace->nr >= init_nr
* and trace-nr <= sysctl_perf_event_max_stack, so trace_nr <= max_depth
*/
@@ -478,6 +466,30 @@ BPF_CALL_3(bpf_get_stackid, struct pt_regs *, regs, struct bpf_map *, map,
return id;
}
+BPF_CALL_3(bpf_get_stackid, struct pt_regs *, regs, struct bpf_map *, map,
+ u64, flags)
+{
+ u32 max_depth = map->value_size / stack_map_data_size(map);
+ /* stack_map_alloc() checks that max_depth <= sysctl_perf_event_max_stack */
+ u32 init_nr = sysctl_perf_event_max_stack - max_depth;
+ bool user = flags & BPF_F_USER_STACK;
+ struct perf_callchain_entry *trace;
+ bool kernel = !user;
+
+ if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER_STACK |
+ BPF_F_FAST_STACK_CMP | BPF_F_REUSE_STACKID)))
+ return -EINVAL;
+
+ trace = get_perf_callchain(regs, init_nr, kernel, user,
+ sysctl_perf_event_max_stack, false, false);
+
+ if (unlikely(!trace))
+ /* couldn't fetch the stack trace */
+ return -EFAULT;
+
+ return __bpf_get_stackid(map, trace, flags);
+}
+
const struct bpf_func_proto bpf_get_stackid_proto = {
.func = bpf_get_stackid,
.gpl_only = true,
@@ -487,7 +499,86 @@ const struct bpf_func_proto bpf_get_stackid_proto = {
.arg3_type = ARG_ANYTHING,
};
+static __u64 count_kernel_ip(struct perf_callchain_entry *trace)
+{
+ __u64 nr_kernel = 0;
+
+ while (nr_kernel < trace->nr) {
+ if (trace->ip[nr_kernel] == PERF_CONTEXT_USER)
+ break;
+ nr_kernel++;
+ }
+ return nr_kernel;
+}
+
+BPF_CALL_3(bpf_get_stackid_pe, struct bpf_perf_event_data_kern *, ctx,
+ struct bpf_map *, map, u64, flags)
+{
+ struct perf_event *event = ctx->event;
+ struct perf_callchain_entry *trace;
+ bool has_kernel, has_user;
+ bool kernel, user;
+
+ /* perf_sample_data doesn't have callchain, use bpf_get_stackid */
+ if (!(event->attr.sample_type & __PERF_SAMPLE_CALLCHAIN_EARLY))
+ return bpf_get_stackid((unsigned long)(ctx->regs),
+ (unsigned long) map, flags, 0, 0);
+
+ if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER_STACK |
+ BPF_F_FAST_STACK_CMP | BPF_F_REUSE_STACKID)))
+ return -EINVAL;
+
+ user = flags & BPF_F_USER_STACK;
+ kernel = !user;
+
+ has_kernel = !event->attr.exclude_callchain_kernel;
+ has_user = !event->attr.exclude_callchain_user;
+
+ if ((kernel && !has_kernel) || (user && !has_user))
+ return -EINVAL;
+
+ trace = ctx->data->callchain;
+ if (unlikely(!trace))
+ return -EFAULT;
+
+ if (has_kernel && has_user) {
+ __u64 nr_kernel = count_kernel_ip(trace);
+ int ret;
+
+ if (kernel) {
+ __u64 nr = trace->nr;
+
+ trace->nr = nr_kernel;
+ ret = __bpf_get_stackid(map, trace, flags);
+
+ /* restore nr */
+ trace->nr = nr;
+ } else { /* user */
+ u64 skip = flags & BPF_F_SKIP_FIELD_MASK;
+
+ skip += nr_kernel;
+ if (skip > BPF_F_SKIP_FIELD_MASK)
+ return -EFAULT;
+
+ flags = (flags & ~BPF_F_SKIP_FIELD_MASK) | skip;
+ ret = __bpf_get_stackid(map, trace, flags);
+ }
+ return ret;
+ }
+ return __bpf_get_stackid(map, trace, flags);
+}
+
+const struct bpf_func_proto bpf_get_stackid_proto_pe = {
+ .func = bpf_get_stackid_pe,
+ .gpl_only = false,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_PTR_TO_CTX,
+ .arg2_type = ARG_CONST_MAP_PTR,
+ .arg3_type = ARG_ANYTHING,
+};
+
static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
+ struct perf_callchain_entry *trace_in,
void *buf, u32 size, u64 flags)
{
u32 init_nr, trace_nr, copy_len, elem_size, num_elem;
@@ -520,7 +611,9 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
else
init_nr = sysctl_perf_event_max_stack - num_elem;
- if (kernel && task)
+ if (trace_in)
+ trace = trace_in;
+ else if (kernel && task)
trace = get_callchain_entry_for_task(task, init_nr);
else
trace = get_perf_callchain(regs, init_nr, kernel, user,
@@ -556,7 +649,7 @@ static long __bpf_get_stack(struct pt_regs *regs, struct task_struct *task,
BPF_CALL_4(bpf_get_stack, struct pt_regs *, regs, void *, buf, u32, size,
u64, flags)
{
- return __bpf_get_stack(regs, NULL, buf, size, flags);
+ return __bpf_get_stack(regs, NULL, NULL, buf, size, flags);
}
const struct bpf_func_proto bpf_get_stack_proto = {
@@ -574,7 +667,7 @@ BPF_CALL_4(bpf_get_task_stack, struct task_struct *, task, void *, buf,
{
struct pt_regs *regs = task_pt_regs(task);
- return __bpf_get_stack(regs, task, buf, size, flags);
+ return __bpf_get_stack(regs, task, NULL, buf, size, flags);
}
BTF_ID_LIST(bpf_get_task_stack_btf_ids)
@@ -591,6 +684,79 @@ const struct bpf_func_proto bpf_get_task_stack_proto = {
.btf_id = bpf_get_task_stack_btf_ids,
};
+BPF_CALL_4(bpf_get_stack_pe, struct bpf_perf_event_data_kern *, ctx,
+ void *, buf, u32, size, u64, flags)
+{
+ struct perf_event *event = ctx->event;
+ struct perf_callchain_entry *trace;
+ bool has_kernel, has_user;
+ bool kernel, user;
+ int err = -EINVAL;
+
+ if (!(event->attr.sample_type & __PERF_SAMPLE_CALLCHAIN_EARLY))
+ return __bpf_get_stack(ctx->regs, NULL, NULL, buf, size, flags);
+
+ if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER_STACK |
+ BPF_F_USER_BUILD_ID)))
+ goto clear;
+
+ user = flags & BPF_F_USER_STACK;
+ kernel = !user;
+
+ has_kernel = !event->attr.exclude_callchain_kernel;
+ has_user = !event->attr.exclude_callchain_user;
+
+ if ((kernel && !has_kernel) || (user && !has_user))
+ goto clear;
+
+ err = -EFAULT;
+ trace = ctx->data->callchain;
+ if (unlikely(!trace))
+ goto clear;
+
+ if (has_kernel && has_user) {
+ __u64 nr_kernel = count_kernel_ip(trace);
+ int ret;
+
+ if (kernel) {
+ __u64 nr = trace->nr;
+
+ trace->nr = nr_kernel;
+ ret = __bpf_get_stack(ctx->regs, NULL, trace, buf,
+ size, flags);
+
+ /* restore nr */
+ trace->nr = nr;
+ } else { /* user */
+ u64 skip = flags & BPF_F_SKIP_FIELD_MASK;
+
+ skip += nr_kernel;
+ if (skip > BPF_F_SKIP_FIELD_MASK)
+ goto clear;
+
+ flags = (flags & ~BPF_F_SKIP_FIELD_MASK) | skip;
+ ret = __bpf_get_stack(ctx->regs, NULL, trace, buf,
+ size, flags);
+ }
+ return ret;
+ }
+ return __bpf_get_stack(ctx->regs, NULL, trace, buf, size, flags);
+clear:
+ memset(buf, 0, size);
+ return err;
+
+}
+
+const struct bpf_func_proto bpf_get_stack_proto_pe = {
+ .func = bpf_get_stack_pe,
+ .gpl_only = true,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_PTR_TO_CTX,
+ .arg2_type = ARG_PTR_TO_UNINIT_MEM,
+ .arg3_type = ARG_CONST_SIZE_OR_ZERO,
+ .arg4_type = ARG_ANYTHING,
+};
+
/* Called from eBPF program */
static void *stack_map_lookup_elem(struct bpf_map *map, void *key)
{
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 3cc0dcb60ca20..cb91ef902cc43 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -1411,9 +1411,9 @@ pe_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
case BPF_FUNC_perf_event_output:
return &bpf_perf_event_output_proto_tp;
case BPF_FUNC_get_stackid:
- return &bpf_get_stackid_proto_tp;
+ return &bpf_get_stackid_proto_pe;
case BPF_FUNC_get_stack:
- return &bpf_get_stack_proto_tp;
+ return &bpf_get_stack_proto_pe;
case BPF_FUNC_perf_prog_read_value:
return &bpf_perf_prog_read_value_proto;
case BPF_FUNC_read_branch_records:
--
2.24.1
^ permalink raw reply related
* + mm-thp-replace-http-links-with-https-ones-fix.patch added to -mm tree
From: Andrew Morton @ 2020-07-16 23:52 UTC (permalink / raw)
To: akpm, grandmaster, mm-commits, vbabka
In-Reply-To: <20200703151445.b6a0cfee402c7c5c4651f1b1@linux-foundation.org>
The patch titled
Subject: mm-thp-replace-http-links-with-https-ones-fix
has been added to the -mm tree. Its filename is
mm-thp-replace-http-links-with-https-ones-fix.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-thp-replace-http-links-with-https-ones-fix.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-thp-replace-http-links-with-https-ones-fix.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Andrew Morton <akpm@linux-foundation.org>
Subject: mm-thp-replace-http-links-with-https-ones-fix
fix amd.com URL, per Vlastimil
Cc: "Alexander A. Klimov" <grandmaster@al2klimov.de>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/huge_memory.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/mm/huge_memory.c~mm-thp-replace-http-links-with-https-ones-fix
+++ a/mm/huge_memory.c
@@ -2065,8 +2065,8 @@ static void __split_huge_pmd_locked(stru
* free), userland could trigger a small page size TLB miss on the
* small sized TLB while the hugepage TLB entry is still established in
* the huge TLB. Some CPU doesn't like that.
- * See https://support.amd.com/us/Processor_TechDocs/41322.pdf, Erratum
- * 383 on page 93. Intel should be safe but is also warns that it's
+ * See http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf, Erratum
+ * 383 on page 105. Intel should be safe but is also warns that it's
* only safe if the permission and cache attributes of the two entries
* loaded in the two TLB is identical (which should be the case here).
* But it is generally safer to never allow small and huge TLB entries
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
mm-close-race-between-munmap-and-expand_upwards-downwards-fix.patch
revert-squashfs-migrate-from-ll_rw_block-usage-to-bio.patch
mm.patch
mm-handle-page-mapping-better-in-dump_page-fix.patch
mm-memcg-percpu-account-percpu-memory-to-memory-cgroups-fix.patch
mm-memcg-percpu-account-percpu-memory-to-memory-cgroups-fix-fix.patch
mm-thp-replace-http-links-with-https-ones-fix.patch
mm-vmstat-add-events-for-thp-migration-without-split-fix.patch
linux-next-rejects.patch
linux-next-git-rejects.patch
mm-migrate-clear-__gfp_reclaim-to-make-the-migration-callback-consistent-with-regular-thp-allocations-fix.patch
mm-madvise-introduce-process_madvise-syscall-an-external-memory-hinting-api-fix.patch
mm-madvise-introduce-process_madvise-syscall-an-external-memory-hinting-api-fix-2.patch
kernel-forkc-export-kernel_thread-to-modules.patch
^ permalink raw reply
* RE: [BlueZ,1/4] shared/att: Fix possible crash on disconnect
From: bluez.test.bot @ 2020-07-16 23:51 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20200716231857.934396-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
While we are preparing for reviewing the patches, we found the following
issue/warning.
Test Result:
makecheck Failed
Outputs:
./test-driver: line 107: 14798 Bus error (core dumped) "$@" > $log_file 2>&1
make[3]: *** [Makefile:9726: test-suite.log] Error 1
make[2]: *** [Makefile:9834: check-TESTS] Error 2
make[1]: *** [Makefile:10228: check-am] Error 2
make: *** [Makefile:10230: check] Error 2
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH 05/11] xfs: refactor quota type testing
From: Dave Chinner @ 2020-07-16 23:51 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-xfs
In-Reply-To: <159488195153.3813063.7311387972463609613.stgit@magnolia>
On Wed, Jul 15, 2020 at 11:45:51PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> Certain functions can only act upon one quota type, so refactor those
> functions to use switch statements, in keeping with all the other high
> level xfs quota api calls.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
> fs/xfs/xfs_dquot.c | 29 ++++++++++++++++++-----------
> fs/xfs/xfs_trans_dquot.c | 15 +++++++++++----
> 2 files changed, 29 insertions(+), 15 deletions(-)
looks good.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH 2/2] repository: allow repository format upgrade with extensions
From: Junio C Hamano @ 2020-07-16 23:50 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jeff King, Johannes Schindelin, Derrick Stolee,
Johannes Schindelin via GitGitGadget, git, delphij,
Huan Huan Chen, brian m. carlson
In-Reply-To: <20200716223719.GA899@gmail.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> - defining the list of repository format v0 supported extensions as
> "these and no more", futureproofing along the lines suggested in
> Peff's patch. I like the general approach taken there since it
> allows parsing the relevant config in a single pass, so I think
> it basically takes the right approach. (That said, it might be
> possible to simplify a bit with further changes, e.g. by using the
> configset API.)
>
> When doing this for real, we'd want to document the set of
> supported extensions. That is especially useful to independent
> implementers wanting to support Git's formats, since it tells
> them "this is the minimum set of extensions that you must
> either handle or error out cleanly on to maintain compatibility
> with Git's repository format v0".
Good.
> - improving the behavior when an extension not supported in v0 is
> encountered in a v0 repository. For extensions that are supported
> in v1 and not v0, we should presumably error out so the user can
> repair the repository, and we can put the "noop" extension in that
> category for the sake of easy testing. We can also include a check
> in "git fsck" for repositories that request the undefined behavior
> of v0 repositories with non-v0 extensions, for faster diagnosis.
>
> What about unrecognized extensions that are potentially extensions
> yet to be defined? Should these be silently ignored to match the
> historical behavior, or should we error out even in repository
> format v0? I lean toward the latter; we'll need to be cautious,
> though, e.g. by making this a separate patch so we can easily tweak
> it if this ends up being disruptive in some unanticipated way.
I disagree with your first paragraph. Those that weren't honored by
mistake back in v0 days, in addition to those that aren't known to us
even now, should just be silently ignored, not causing an error.
> - making "git init" use repository format v1 by default. It's been
> long enough that users can count on Git implementations supporting
> it. This way, users are less likely to run into v0+extensions
> confusion, just because users are less likely to be using v0.
Absolutely. I would think this is a very good move.
> Does that sound like a good plan to others? If so, are there any
> steps beyond the two first patches in jn/v0-with-extensions-fix that
> we would want in order to prepare for it in 2.28?
>
> My preference would be to move forward in 2.28 with the first two
> patches in that topic branch (i.e., *not* the third yet), since they
> don't produce any user facing behavior that would create danger for
> users or clash with this plan.
Yup, I agree. I'd give another name to the third commit and then
rewind jn/v0-with-extensions-fix by one to prevent mistakes from
happening. Thanks.
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move WaDisableDopClockGating:skl to skl_init_clock_gating()
From: Souza, Jose @ 2020-07-16 23:50 UTC (permalink / raw)
To: ville.syrjala@linux.intel.com, intel-gfx@lists.freedesktop.org
In-Reply-To: <20200716190426.17047-1-ville.syrjala@linux.intel.com>
On Thu, 2020-07-16 at 22:04 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> It's silly to have if(SKL) checks in gen9_init_clock_gating() when
> we can just move those bits into skl_init_clock_gating().
>
> I'm not entirely convinced we even need this w/a, or if we do
> then maybe we want it for kbl/cfl as well. IIRC it was only
> listed in the wadb, but that is now dead so can't double check
> anymore. Bspec doesn't seem to have any purely skl specific
> DOP clock gating workarounds listed.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> Probably should move this to the gt w/a code actually. But
> there's a lot more gt related stuff still in .init_clock_gating()
> so should grab a bigger shovel to move it all in one go.
>
> drivers/gpu/drm/i915/intel_pm.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index cfabbe0481ab..0a1a95060f38 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -100,12 +100,6 @@ static void gen9_init_clock_gating(struct drm_i915_private *dev_priv)
> */
> I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) |
> DISP_FBC_MEMORY_WAKE);
> -
> - if (IS_SKYLAKE(dev_priv)) {
> - /* WaDisableDopClockGating */
> - I915_WRITE(GEN7_MISCCPCTL, I915_READ(GEN7_MISCCPCTL)
> - & ~GEN7_DOP_CLOCK_GATE_ENABLE);
> - }
> }
>
> static void bxt_init_clock_gating(struct drm_i915_private *dev_priv)
> @@ -7251,6 +7245,10 @@ static void skl_init_clock_gating(struct drm_i915_private *dev_priv)
> {
> gen9_init_clock_gating(dev_priv);
>
> + /* WaDisableDopClockGating:skl */
> + I915_WRITE(GEN7_MISCCPCTL, I915_READ(GEN7_MISCCPCTL) &
> + ~GEN7_DOP_CLOCK_GATE_ENABLE);
> +
> /* WAC6entrylatency:skl */
> I915_WRITE(FBC_LLC_READ_CTRL, I915_READ(FBC_LLC_READ_CTRL) |
> FBC_LLC_FULLY_OPEN);
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: clean up address limit helpers v2
From: Andrew Morton @ 2020-07-16 23:49 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, Nick Hu, linux-kernel, Palmer Dabbelt, Greentime Hu,
Paul Walmsley, linux-riscv, Vincent Chen, Linus Torvalds
In-Reply-To: <20200714105505.935079-1-hch@lst.de>
On Tue, 14 Jul 2020 12:54:59 +0200 Christoph Hellwig <hch@lst.de> wrote:
> Hi all,
>
> in preparation for eventually phasing out direct use of set_fs(), this
> series removes the segment_eq() arch helper that is only used to
> implement or duplicate the uaccess_kernel() API, and then adds
> descriptive helpers to force the kernel address limit.
>
>
> Changes since v1:
> - drop to incorrect hunks
> - fix a commit log typo
I think this *is* v1. I can't find any differences in the patches and I
was unable to eyeball any changelog alterations?
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH 04/11] xfs: remove the XFS_QM_IS[UGP]DQ macros
From: Dave Chinner @ 2020-07-16 23:49 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-xfs
In-Reply-To: <159488194524.3813063.1536581067461068233.stgit@magnolia>
On Wed, Jul 15, 2020 at 11:45:45PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> Remove these macros and use xfs_dquot_type() for everything.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
> fs/xfs/xfs_dquot.h | 9 ++++++---
> fs/xfs/xfs_qm.h | 11 -----------
> fs/xfs/xfs_trans_dquot.c | 15 ++++++++++-----
> 3 files changed, 16 insertions(+), 19 deletions(-)
Seems reasonable.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: clean up address limit helpers v2
From: Andrew Morton @ 2020-07-16 23:49 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Nick Hu, Greentime Hu, Vincent Chen, Paul Walmsley,
Palmer Dabbelt, Linus Torvalds, linux-riscv, linux-arch,
linux-kernel
In-Reply-To: <20200714105505.935079-1-hch@lst.de>
On Tue, 14 Jul 2020 12:54:59 +0200 Christoph Hellwig <hch@lst.de> wrote:
> Hi all,
>
> in preparation for eventually phasing out direct use of set_fs(), this
> series removes the segment_eq() arch helper that is only used to
> implement or duplicate the uaccess_kernel() API, and then adds
> descriptive helpers to force the kernel address limit.
>
>
> Changes since v1:
> - drop to incorrect hunks
> - fix a commit log typo
I think this *is* v1. I can't find any differences in the patches and I
was unable to eyeball any changelog alterations?
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v8 5/5] drm/i915/rkl: Add Wa_14011224835 for PHY B initialization
From: Souza, Jose @ 2020-07-16 23:49 UTC (permalink / raw)
To: Roper, Matthew D, intel-gfx@lists.freedesktop.org
In-Reply-To: <20200716220551.2730644-6-matthew.d.roper@intel.com>
On Thu, 2020-07-16 at 15:05 -0700, Matt Roper wrote:
> After doing normal PHY-B initialization on Rocket Lake, we need to
> manually copy some additional PHY-A register values into PHY-B
> registers.
>
> Note that the bspec's combo phy page doesn't specify that this
> workaround is restricted to specific platform steppings (and doesn't
> even do a very good job of specifying that RKL is the only platform this
> is needed on), but the RKL workaround page lists this as relevant only
> for A and B steppings, so I'm trusting that information for now.
>
> v2: Make rkl_combo_phy_b_init_wa() static
>
> v3:
> - Minimize variables in WA function. (Jose)
> - Fix timeout duration (usec vs msec). (Jose)
> - Add verification of workaround. (Jose)
> - Fix stepping bounds in comment.
>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> Bspec: 49291
> Bspec: 53273
> Cc: José Roberto de Souza <jose.souza@intel.com>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> ---
> .../gpu/drm/i915/display/intel_combo_phy.c | 50 +++++++++++++++++++
> drivers/gpu/drm/i915/i915_reg.h | 13 ++++-
> 2 files changed, 62 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> index eccaa79cb4a9..d88f91038428 100644
> --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> @@ -255,6 +255,26 @@ static bool phy_is_master(struct drm_i915_private *dev_priv, enum phy phy)
> return phy == PHY_A;
> }
>
> +static bool verify_wa14011224835(struct drm_i915_private *i915)
> +{
> + u32 grccode, val;
> + bool ret = true;
> +
> + grccode = REG_FIELD_GET(GRCCODE,
> + intel_de_read(i915, ICL_PORT_COMP_DW6(PHY_A)));
> + val = REG_FIELD_PREP(IREF_RCAL_ORD, grccode);
> + ret &= check_phy_reg(i915, PHY_B, ICL_PORT_COMP_DW2(PHY_B),
> + IREF_RCAL_ORD, val);
> +
> + grccode = REG_FIELD_GET(GRCCODE_LDO,
> + intel_de_read(i915, ICL_PORT_COMP_DW0(PHY_A)));
> + val = REG_FIELD_PREP(RCOMPCODE_LD_CAP_OV, grccode);
> + ret &= check_phy_reg(i915, PHY_B, ICL_PORT_COMP_DW2(PHY_B),
> + IREF_RCAL_ORD, val);
> +
> + return ret;
> +}
> +
> static bool icl_combo_phy_verify_state(struct drm_i915_private *dev_priv,
> enum phy phy)
> {
> @@ -295,6 +315,11 @@ static bool icl_combo_phy_verify_state(struct drm_i915_private *dev_priv,
> ret &= check_phy_reg(dev_priv, phy, ICL_PORT_CL_DW5(phy),
> CL_POWER_DOWN_ENABLE, CL_POWER_DOWN_ENABLE);
>
> + /* Wa_14011224835:rkl[a0..b0] */
> + if (IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_B0) &&
> + phy == PHY_B)
> + ret &= verify_wa14011224835(dev_priv);
> +
> return ret;
> }
>
> @@ -350,6 +375,26 @@ void intel_combo_phy_power_up_lanes(struct drm_i915_private *dev_priv,
> intel_de_write(dev_priv, ICL_PORT_CL_DW10(phy), val);
> }
>
> +static void rkl_combo_phy_b_init_wa(struct drm_i915_private *i915)
> +{
> + u32 grccode, val;
> +
> + wait_for_us(intel_de_read(i915, ICL_PORT_COMP_DW3(PHY_A)) &
> + FIRST_COMP_DONE, 100);
> +
> + grccode = REG_FIELD_GET(GRCCODE,
> + intel_de_read(i915, ICL_PORT_COMP_DW6(PHY_A)));
> + val = REG_FIELD_PREP(IREF_RCAL_ORD, grccode);
> + intel_de_rmw(i915, ICL_PORT_COMP_DW2(PHY_B), IREF_RCAL_ORD,
> + val | IREF_RCAL_ORD_EN);
> +
> + grccode = REG_FIELD_GET(GRCCODE_LDO,
> + intel_de_read(i915, ICL_PORT_COMP_DW0(PHY_A)));
> + val = REG_FIELD_PREP(RCOMPCODE_LD_CAP_OV, grccode);
> + intel_de_rmw(i915, ICL_PORT_COMP_DW6(PHY_B), RCOMPCODE_LD_CAP_OV,
> + val | RCOMPCODEOVEN_LDO_SYNC);
> +}
> +
> static void icl_combo_phys_init(struct drm_i915_private *dev_priv)
> {
> enum phy phy;
> @@ -415,6 +460,11 @@ static void icl_combo_phys_init(struct drm_i915_private *dev_priv)
> val = intel_de_read(dev_priv, ICL_PORT_CL_DW5(phy));
> val |= CL_POWER_DOWN_ENABLE;
> intel_de_write(dev_priv, ICL_PORT_CL_DW5(phy), val);
> +
> + if (IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_B0) &&
> + phy == PHY_B)
> + /* Wa_14011224835:rkl[a0..b0] */
> + rkl_combo_phy_b_init_wa(dev_priv);
> }
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 89a9f2d8110e..a0d31f3bf634 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1911,11 +1911,16 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>
> #define CNL_PORT_COMP_DW0 _MMIO(0x162100)
> #define ICL_PORT_COMP_DW0(phy) _MMIO(_ICL_PORT_COMP_DW(0, phy))
> -#define COMP_INIT (1 << 31)
> +#define COMP_INIT REG_BIT(31)
> +#define GRCCODE_LDO REG_GENMASK(7, 0)
>
> #define CNL_PORT_COMP_DW1 _MMIO(0x162104)
> #define ICL_PORT_COMP_DW1(phy) _MMIO(_ICL_PORT_COMP_DW(1, phy))
>
> +#define ICL_PORT_COMP_DW2(phy) _MMIO(_ICL_PORT_COMP_DW(2, phy))
> +#define IREF_RCAL_ORD_EN REG_BIT(7)
> +#define IREF_RCAL_ORD REG_GENMASK(6, 0)
> +
> #define CNL_PORT_COMP_DW3 _MMIO(0x16210c)
> #define ICL_PORT_COMP_DW3(phy) _MMIO(_ICL_PORT_COMP_DW(3, phy))
> #define PROCESS_INFO_DOT_0 (0 << 26)
> @@ -1928,6 +1933,12 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> #define VOLTAGE_INFO_1_05V (2 << 24)
> #define VOLTAGE_INFO_MASK (3 << 24)
> #define VOLTAGE_INFO_SHIFT 24
> +#define FIRST_COMP_DONE REG_BIT(22)
> +
> +#define ICL_PORT_COMP_DW6(phy) _MMIO(_ICL_PORT_COMP_DW(6, phy))
> +#define GRCCODE REG_GENMASK(30, 24)
> +#define RCOMPCODEOVEN_LDO_SYNC REG_BIT(23)
> +#define RCOMPCODE_LD_CAP_OV REG_GENMASK(22, 16)
>
> #define ICL_PORT_COMP_DW8(phy) _MMIO(_ICL_PORT_COMP_DW(8, phy))
> #define IREFGEN (1 << 24)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* RE: [BlueZ,1/4] shared/att: Fix possible crash on disconnect
From: bluez.test.bot @ 2020-07-16 23:48 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20200716231857.934396-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
While we are preparing for reviewing the patches, we found the following
issue/warning.
Test Result:
checkpatch Failed
Outputs:
WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#17:
by 0x48E963B: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.6400.4)
- total: 0 errors, 1 warnings, 83 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
Your patch has style problems, please review.
NOTE: Ignored message types: COMMIT_MESSAGE COMPLEX_MACRO CONST_STRUCT FILE_PATH_CHANGES MISSING_SIGN_OFF PREFER_PACKED SPLIT_STRING SSCANF_TO_KSTRTO
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [RFC PATCH v3 16/18] gpu: host1x: mipi: Split tegra_mipi_calibrate and tegra_mipi_wait
From: Dmitry Osipenko @ 2020-07-16 23:47 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding, jonathanh, frankc, hverkuil,
sakari.ailus, robh+dt, helen.koike
Cc: sboyd, gregkh, linux-media, devicetree, linux-tegra, linux-kernel,
linux-i2c
In-Reply-To: <66812127-38cf-2af3-51c0-50edbe446e73@nvidia.com>
17.07.2020 02:09, Sowjanya Komatineni пишет:
>
> On 7/16/20 4:06 PM, Sowjanya Komatineni wrote:
>>
>> On 7/16/20 4:01 PM, Dmitry Osipenko wrote:
>>> 17.07.2020 01:49, Sowjanya Komatineni пишет:
>>>>> What keeps MIPI clock enabled after completion of the
>>>>> tegra_mipi_calibrate() invocation?
>>>> MIPI clock is disabled at end of tegra_mipi_calibrate and is re-enabled
>>>> during tegra_mipi_wait.
>>>>
>>>> I think I should fix this to keep the clock enabled till calibration
>>>> results are latched.
>>>>
>>>> All consumers of tegra_mipi_calibrate() will call tegra_mipi_wait().
>>>>
>>>> So will remove clk_disable mipi clk at end of tegra_mipi_calibrate()
>>>> and
>>>> clk_enable mipi_clk at beginning of tegra_mipi_wait()
>>> Isn't it possible to perform the calibration after enabling CSI and
>>> before of starting the sensor streaming?
>> Currently this is what I am doing. Triggering calibration start during
>> CSI receiver being ready and then sensor streaming will happen where
>> internal MIPI CAL detects for LP -> HS transition and applies results
>> to pads. So checking for calibration results after sensor stream is
>> enabled
>
> 1. Calling tegra_mipi_calibrate() during CSI streaming where CSI pads
> are enabled and receiver is kept ready
>
> 2. Start Sensor stream
>
> 3. Calling tegra_mipi_wait() to check for MIPI Cal status.
>
> So as mipi cal clk need to be kept enabled till 3rd step, we can enable
> clock during tegra_mipi_calibrate() and leave it enabled and disable it
> in tegra_mipi_wait after status check.
From TRM:
The following sequence is recommended for capturing a single frame:
1. Set up CSI registers for use case such as number of lanes, virtual
channel, etc.
2. Initialize and power up CSI interface
3. Wait for initialization time or done signal from calibration logic
4. Power up camera through the I2C interface
5. All CSI data and clock lanes are in stop state, LP11
6. Initiate frame capture through the I2C
7. Frame done, CSI goes back to stop state, LP11
Hence, is it really necessary to perform the manual calibration?
^ permalink raw reply
* Re: [RFC PATCH v3 16/18] gpu: host1x: mipi: Split tegra_mipi_calibrate and tegra_mipi_wait
From: Dmitry Osipenko @ 2020-07-16 23:47 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, frankc-DDmLM1+adcrQT0dZR+AlfA,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw, sakari.ailus-X3B1VOXEql0,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
helen.koike-ZGY8ohtN/8qB+jHODAdFcQ
Cc: sboyd-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <66812127-38cf-2af3-51c0-50edbe446e73-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
17.07.2020 02:09, Sowjanya Komatineni пишет:
>
> On 7/16/20 4:06 PM, Sowjanya Komatineni wrote:
>>
>> On 7/16/20 4:01 PM, Dmitry Osipenko wrote:
>>> 17.07.2020 01:49, Sowjanya Komatineni пишет:
>>>>> What keeps MIPI clock enabled after completion of the
>>>>> tegra_mipi_calibrate() invocation?
>>>> MIPI clock is disabled at end of tegra_mipi_calibrate and is re-enabled
>>>> during tegra_mipi_wait.
>>>>
>>>> I think I should fix this to keep the clock enabled till calibration
>>>> results are latched.
>>>>
>>>> All consumers of tegra_mipi_calibrate() will call tegra_mipi_wait().
>>>>
>>>> So will remove clk_disable mipi clk at end of tegra_mipi_calibrate()
>>>> and
>>>> clk_enable mipi_clk at beginning of tegra_mipi_wait()
>>> Isn't it possible to perform the calibration after enabling CSI and
>>> before of starting the sensor streaming?
>> Currently this is what I am doing. Triggering calibration start during
>> CSI receiver being ready and then sensor streaming will happen where
>> internal MIPI CAL detects for LP -> HS transition and applies results
>> to pads. So checking for calibration results after sensor stream is
>> enabled
>
> 1. Calling tegra_mipi_calibrate() during CSI streaming where CSI pads
> are enabled and receiver is kept ready
>
> 2. Start Sensor stream
>
> 3. Calling tegra_mipi_wait() to check for MIPI Cal status.
>
> So as mipi cal clk need to be kept enabled till 3rd step, we can enable
> clock during tegra_mipi_calibrate() and leave it enabled and disable it
> in tegra_mipi_wait after status check.
From TRM:
The following sequence is recommended for capturing a single frame:
1. Set up CSI registers for use case such as number of lanes, virtual
channel, etc.
2. Initialize and power up CSI interface
3. Wait for initialization time or done signal from calibration logic
4. Power up camera through the I2C interface
5. All CSI data and clock lanes are in stop state, LP11
6. Initiate frame capture through the I2C
7. Frame done, CSI goes back to stop state, LP11
Hence, is it really necessary to perform the manual calibration?
^ permalink raw reply
* Re: [PATCH 03/11] xfs: refactor testing if a particular dquot is being enforced
From: Dave Chinner @ 2020-07-16 23:47 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-xfs
In-Reply-To: <159488193887.3813063.5488114906141814243.stgit@magnolia>
On Wed, Jul 15, 2020 at 11:45:39PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> Create a small helper to test if enforcement is enabled for a
> given incore dquot and replace the open-code logic testing.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
> fs/xfs/xfs_dquot.h | 17 +++++++++++++++++
> fs/xfs/xfs_qm_syscalls.c | 9 ++-------
> fs/xfs/xfs_trans_dquot.c | 4 +---
> 3 files changed, 20 insertions(+), 10 deletions(-)
>
looks ok to me.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v8 4/5] drm/i915/rkl: Handle HTI
From: Souza, Jose @ 2020-07-16 23:47 UTC (permalink / raw)
To: Roper, Matthew D, intel-gfx@lists.freedesktop.org; +Cc: De Marchi, Lucas
In-Reply-To: <20200716220551.2730644-5-matthew.d.roper@intel.com>
On Thu, 2020-07-16 at 15:05 -0700, Matt Roper wrote:
> If HTI (also sometimes called HDPORT) is enabled at startup, it may be
> using some of the PHYs and DPLLs making them unavailable for general
> usage. Let's read out the HDPORT_STATE register and avoid making use of
> resources that HTI is already using.
>
> v2:
> - Fix minor checkpatch warnings
>
> v3:
> - Just readout HDPORT_STATE register once during init and then parse it
> later as needed.
> - Add a 'has_hti' device info flag to track whether we should readout
> HDPORT_STATE or not. We can skip the platform/flag tests later since
> the hti_state in dev_priv will remain 0 for platforms it does not
> apply to.
> - Move PLL masking into icl_get_combo_phy_dpll() since at the moment
> RKL is the only platform that has HTI. (Jose)
>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> Bspec: 49189
> Bspec: 53707
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Cc: José Roberto de Souza <jose.souza@intel.com>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 19 +++++++++++++++++++
> drivers/gpu/drm/i915/display/intel_display.c | 8 ++++++++
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 11 +++++++++++
> drivers/gpu/drm/i915/i915_drv.h | 8 ++++++++
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> drivers/gpu/drm/i915/i915_reg.h | 6 ++++++
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> 7 files changed, 54 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 1ca70f9abc8d..714b2bc96f23 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4923,6 +4923,13 @@ intel_ddi_max_lanes(struct intel_digital_port *dig_port)
> return max_lanes;
> }
>
> +static bool hti_uses_phy(struct drm_i915_private *i915, enum phy phy)
> +{
> + return i915->hti_state & HDPORT_ENABLED &&
> + (i915->hti_state & HDPORT_PHY_USED_DP(phy) ||
> + i915->hti_state & HDPORT_PHY_USED_HDMI(phy));
> +}
> +
> void intel_ddi_init(struct drm_i915_private *dev_priv, enum port port)
> {
> struct intel_digital_port *dig_port;
> @@ -4930,6 +4937,18 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, enum port port)
> bool init_hdmi, init_dp, init_lspcon = false;
> enum phy phy = intel_port_to_phy(dev_priv, port);
>
> + /*
> + * On platforms with HTI (aka HDPORT), if it's enabled at boot it may
> + * have taken over some of the PHYs and made them unavailable to the
> + * driver. In that case we should skip initializing the corresponding
> + * outputs.
> + */
> + if (hti_uses_phy(dev_priv, phy)) {
> + drm_dbg_kms(&dev_priv->drm, "PORT %c / PHY %c reserved by HTI\n",
> + port_name(port), phy_name(phy));
> + return;
> + }
> +
> init_hdmi = intel_bios_port_supports_dvi(dev_priv, port) ||
> intel_bios_port_supports_hdmi(dev_priv, port);
> init_dp = intel_bios_port_supports_dp(dev_priv, port);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index 6cb66580ad2c..db2a5a1a9b35 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -47,6 +47,7 @@
> #include "display/intel_ddi.h"
> #include "display/intel_dp.h"
> #include "display/intel_dp_mst.h"
> +#include "display/intel_dpll_mgr.h"
> #include "display/intel_dsi.h"
> #include "display/intel_dvo.h"
> #include "display/intel_gmbus.h"
> @@ -17903,6 +17904,13 @@ int intel_modeset_init(struct drm_i915_private *i915)
> if (i915->max_cdclk_freq == 0)
> intel_update_max_cdclk(i915);
>
> + /*
> + * If the platform has HTI, we need to find out whether it has reserved
> + * any display resources before we create our display outputs.
> + */
> + if (INTEL_INFO(i915)->display.has_hti)
> + i915->hti_state = intel_de_read(i915, HDPORT_STATE);
> +
> /* Just disable it once at startup */
> intel_vga_disable(i915);
> intel_setup_outputs(i915);
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 134c2ecf4c80..81ab975fe4f0 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -3475,6 +3475,14 @@ static void icl_update_active_dpll(struct intel_atomic_state *state,
> icl_set_active_port_dpll(crtc_state, port_dpll_id);
> }
>
> +static u32 intel_get_hti_plls(struct drm_i915_private *i915)
> +{
> + if (!(i915->hti_state & HDPORT_ENABLED))
> + return 0;
> +
> + return REG_FIELD_GET(HDPORT_DPLL_USED_MASK, i915->hti_state);
> +}
> +
> static bool icl_get_combo_phy_dpll(struct intel_atomic_state *state,
> struct intel_crtc *crtc,
> struct intel_encoder *encoder)
> @@ -3518,6 +3526,9 @@ static bool icl_get_combo_phy_dpll(struct intel_atomic_state *state,
> dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
> }
>
> + /* Eliminate DPLLs from consideration if reserved by HTI */
> + dpll_mask &= ~intel_get_hti_plls(dev_priv);
> +
> port_dpll->pll = intel_find_shared_dpll(state, crtc,
> &port_dpll->hw_state,
> dpll_mask);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e4f7f6518945..56dfc6d98caa 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1044,6 +1044,14 @@ struct drm_i915_private {
>
> struct intel_l3_parity l3_parity;
>
> + /*
> + * HTI (aka HDPORT) state read during initial hw readout. Most
> + * platforms don't have HTI, so this will just stay 0. Those that do
> + * will use this later to figure out which PLLs and PHYs are unavailable
> + * for driver usage.
> + */
> + u32 hti_state;
> +
> /*
> * edram size in MB.
> * Cannot be determined by PCIID. You must always read a register.
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 2338f92ce490..366ddfc8df6b 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -890,6 +890,7 @@ static const struct intel_device_info rkl_info = {
> .cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
> BIT(TRANSCODER_C),
> .require_force_probe = 1,
> + .display.has_hti = 1,
> .display.has_psr_hw_tracking = 0,
> .platform_engine_mask =
> BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0),
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index bfdb6d23b5d8..89a9f2d8110e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2921,6 +2921,12 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> #define MBUS_BBOX_CTL_S1 _MMIO(0x45040)
> #define MBUS_BBOX_CTL_S2 _MMIO(0x45044)
>
> +#define HDPORT_STATE _MMIO(0x45050)
> +#define HDPORT_DPLL_USED_MASK REG_GENMASK(14, 12)
> +#define HDPORT_PHY_USED_DP(phy) REG_BIT(2 * (phy) + 2)
> +#define HDPORT_PHY_USED_HDMI(phy) REG_BIT(2 * (phy) + 1)
> +#define HDPORT_ENABLED REG_BIT(0)
> +
> /* Make render/texture TLB fetches lower priorty than associated data
> * fetches. This is not turned on by default
> */
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h
> index fd2385457ab6..6a3d607218aa 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -146,6 +146,7 @@ enum intel_ppgtt_type {
> func(has_gmch); \
> func(has_hdcp); \
> func(has_hotplug); \
> + func(has_hti); \
> func(has_ipc); \
> func(has_modular_fia); \
> func(has_overlay); \
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH v3 bpf-next 0/2] bpf: fix stackmap on perf_events with PEBS
From: Song Liu @ 2020-07-16 22:59 UTC (permalink / raw)
To: linux-kernel, bpf, netdev
Cc: ast, daniel, kernel-team, john.fastabend, kpsingh, brouer, peterz,
Song Liu
Calling get_perf_callchain() on perf_events from PEBS entries may cause
unwinder errors. To fix this issue, perf subsystem fetches callchain early,
and marks perf_events are marked with __PERF_SAMPLE_CALLCHAIN_EARLY.
Similar issue exists when BPF program calls get_perf_callchain() via
helper functions. For more information about this issue, please refer to
discussions in [1].
This set fixes this issue with helper proto bpf_get_stackid_pe and
bpf_get_stack_pe.
[1] https://lore.kernel.org/lkml/ED7B9430-6489-4260-B3C5-9CFA2E3AA87A@fb.com/
Changes v2 => v3:
1. Fix handling of stackmap skip field. (Andrii)
2. Simplify the code in a few places. (Andrii)
Changes v1 => v2:
1. Simplify the design and avoid introducing new helper function. (Andrii)
Song Liu (2):
bpf: separate bpf_get_[stack|stackid] for perf events BPF
selftests/bpf: add callchain_stackid
include/linux/bpf.h | 2 +
kernel/bpf/stackmap.c | 202 ++++++++++++++++--
kernel/trace/bpf_trace.c | 4 +-
.../bpf/prog_tests/perf_event_stackmap.c | 116 ++++++++++
.../selftests/bpf/progs/perf_event_stackmap.c | 59 +++++
5 files changed, 363 insertions(+), 20 deletions(-)
create mode 100644 tools/testing/selftests/bpf/prog_tests/perf_event_stackmap.c
create mode 100644 tools/testing/selftests/bpf/progs/perf_event_stackmap.c
--
2.24.1
^ permalink raw reply
* RE: [PATCH 1/2] pinctrl: imx: Support building SCU pinctrl driver as module
From: Anson Huang @ 2020-07-16 23:44 UTC (permalink / raw)
To: Daniel Baluta, Aisheng Dong, festevam@gmail.com,
shawnguo@kernel.org, stefan@agner.ch, kernel@pengutronix.de,
linus.walleij@linaro.org, s.hauer@pengutronix.de,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: dl-linux-imx
In-Reply-To: <5e2af0c3-c832-3978-017e-0b1649aac61c@nxp.com>
Hi, Daniel
> Subject: Re: [PATCH 1/2] pinctrl: imx: Support building SCU pinctrl driver as
> module
>
> On 7/16/20 6:21 PM, Anson Huang wrote:
> > Hi, Daniel
> >
> >
> >> Subject: Re: [PATCH 1/2] pinctrl: imx: Support building SCU pinctrl
> >> driver as module
> >>
> >> Hi Anson,
> >>
> >> Few comments inline:
> >>
> >> On 7/16/20 6:06 PM, Anson Huang wrote:
> >>> To support building i.MX SCU pinctrl driver as module, below things
> >>> need to
> >> be changed:
> >>> - Export SCU related functions and use "IS_ENABLED" instead of
> >>> "ifdef" to support SCU pinctrl driver user and itself to be
> >>> built as module;
> >>> - Use function callbacks for SCU related functions in pinctrl-imx.c
> >>> in order to support the scenario of PINCTRL_IMX is built in
> >>> while PINCTRL_IMX_SCU is built as module;
> >>> - All drivers using SCU pinctrl driver need to initialize the
> >>> SCU related function callback;
> >>> - Change PINCTR_IMX_SCU to tristate;
> >>> - Add module author, description and license.
> >>>
> >>> With above changes, i.MX SCU pinctrl driver can be built as module.
> >>
> >> There are a lot of changes here. I think it would be better to try to
> >> split them
> >>
> >> per functionality. One functional change per patch.
> > Actually, I ever tried to split them, but the function will be broken.
> > All the changes are just to support the module build. If split them,
> > the bisect will have pinctrl build or function broken.
>
> Hi Anson,
>
>
> I see your point and I know that this is a very hard task to get it right from
>
> the first patches.
>
> But let me suggest at least that:
>
> - changes in drivers/pinctrl/freescale/pinctrl-imx.c (include file and
> MODULE_ macros should go to a separate patch).
You meant in patch #2, the changes in Kconfig and the changes in .c file should
be split to 2 patches?
Thanks,
Anson
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next 0/3] Fully describe the waveform for PTP periodic output
From: Jakub Kicinski @ 2020-07-16 22:28 UTC (permalink / raw)
To: Vladimir Oltean
Cc: davem, netdev, richardcochran, jacob.e.keller, yangbo.lu,
xiaoliang.yang_1, po.liu, UNGLinuxDriver
In-Reply-To: <20200716212032.1024188-1-olteanv@gmail.com>
On Fri, 17 Jul 2020 00:20:29 +0300 Vladimir Oltean wrote:
> While using the ancillary pin functionality of PTP hardware clocks to
> synchronize multiple DSA switches on a board, a need arised to be able
> to configure the duty cycle of the master of this PPS hierarchy.
>
> Also, the PPS master is not able to emit PPS starting from arbitrary
> absolute times, so a new flag is introduced to support such hardware
> without making guesses.
>
> With these patches, struct ptp_perout_request now basically describes a
> general-purpose square wave.
error: patch failed: drivers/net/ethernet/mscc/ocelot_ptp.c:236
error: drivers/net/ethernet/mscc/ocelot_ptp.c: patch does not apply
hint: Use 'git am --show-current-patch' to see the failed patch
Applying: ptp: add ability to configure duty cycle for periodic output
Applying: ptp: introduce a phase offset in the periodic output request
Applying: net: mscc: ocelot: add support for PTP waveform configuration
Patch failed at 0003 net: mscc: ocelot: add support for PTP waveform configuration
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: mscc: ocelot: add support for PTP waveform configuration
From: Jakub Kicinski @ 2020-07-16 22:29 UTC (permalink / raw)
To: Vladimir Oltean
Cc: davem, netdev, richardcochran, jacob.e.keller, yangbo.lu,
xiaoliang.yang_1, po.liu, UNGLinuxDriver
In-Reply-To: <20200716213622.zlsmaz56io4d6vgl@skbuf>
On Fri, 17 Jul 2020 00:36:22 +0300 Vladimir Oltean wrote:
> which I used for testing until I exposed this into an ioctl. I knew I
> forgot to do something, and that was to squash that patch into this one.
> So I'll need to send a v2, because otherwise this doesn't apply to
> mainline. Please review taking this into consideration.
Ah, only noticed this now.
^ permalink raw reply
* Re: [PATCH] ASoC: soc-jack: calling snd_soc_jack_report causes a null pointer access
From: Mark Brown @ 2020-07-16 22:29 UTC (permalink / raw)
To: mnlife qiao; +Cc: lgirdwood, Jaroslav Kysela, open list, alsa-devel, mnlife
In-Reply-To: <CAGjHXR2ExzMO3ntwzZy9QUhpuqe-VZAXOucNkXXZK+0XZcaQWQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
On Wed, Jul 15, 2020 at 08:24:04AM +0800, mnlife qiao wrote:
> When snd_soc_card_jack_new is not called or the call fails,
> calling this function causes a null pointer access
> --- a/sound/soc/soc-jack.c
> +++ b/sound/soc/soc-jack.c
> @@ -44,7 +44,7 @@ void snd_soc_jack_report(struct snd_soc_jack *jack, int status, int mask)
> unsigned int sync = 0;
> int enable;
>
> - if (!jack)
> + if (!jack || !jack->jack)
> return;
I'm afraid this still won't apply - there's a text/html version of the
patch, in the text portion tabs have been converted into spaces and it
appears some other issues that mean git am can't understand it.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [net-next 12/15] net/mlx5e: XDP, Avoid indirect call in TX flow
From: Jakub Kicinski @ 2020-07-16 22:26 UTC (permalink / raw)
To: Saeed Mahameed; +Cc: David S. Miller, netdev, Tariq Toukan, Maxim Mikityanskiy
In-Reply-To: <20200716213321.29468-13-saeedm@mellanox.com>
On Thu, 16 Jul 2020 14:33:18 -0700 Saeed Mahameed wrote:
> From: Tariq Toukan <tariqt@mellanox.com>
>
> Use INDIRECT_CALL_2() helper to avoid the cost of the indirect call
> when/if CONFIG_RETPOLINE=y.
>
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> Reviewed-by: Maxim Mikityanskiy <maximmi@mellanox.com>
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Are these expected?
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:251:29: warning: symbol 'mlx5e_xmit_xdp_frame_check_mpwqe' was not declared. Should it be static?
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:306:29: warning: symbol 'mlx5e_xmit_xdp_frame_check' was not declared. Should it be static?
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:251:29: warning: no previous prototype for ‘mlx5e_xmit_xdp_frame_check_mpwqe’ [-Wmissing-prototypes]
251 | INDIRECT_CALLABLE_SCOPE int mlx5e_xmit_xdp_frame_check_mpwqe(struct mlx5e_xdpsq *sq)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c:306:29: warning: no previous prototype for ‘mlx5e_xmit_xdp_frame_check’ [-Wmissing-prototypes]
306 | INDIRECT_CALLABLE_SCOPE int mlx5e_xmit_xdp_frame_check(struct mlx5e_xdpsq *sq)
|
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.